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An  Architecture  to  Support  Large 
N  umbers  of  Computer-Generated 
Actors  for  Distributed  Virtual 
Environments 


Abstract 

A  variety  of  challenges  exist  in  the  design  of  systems  that  can  be  used  to  host  a  wide 
variety  of  computer-generated  actors  (CGAs)  that  possess  believable  behaviors.  The 
challenges  arise  in  the  areas  of  system  architecture  and  design,  knowledge-base  design, 
decision-making  mechanisms,  and  the  distributed  virtual  environment  (DVE)  network 
interface.  These  challenges  are  especially  significant  if  the  DVE  is  to  be  used  for  train¬ 
ing,  because  accurate  training  is  essential  to  the  ready  application  of  training  experi¬ 
ence  to  real-world  situations.  The  project  described  in  this  paper  was  undertaken  to 
improve  the  quality  of  threat  CGAs  in  DVEs  utilized  for  aircrew  training.  In  this  paper, 
we  describe  the  system  and  the  reasons  for  its  genesis.  W  e  present  the  system  re¬ 
quirements,  system  architecture,  component-wise  decomposition  of  the  system  de¬ 
sign,  and  structure  of  the  major  components  of  the  decision  mechanism.  W  e  conclude 
with  a  summary  of  our  results  to  date  and  recommendations  for  further  research. 


1  Introduction 

TheJ  oint  Synthetic  Battlespace  (J  SB)  proposed  within  the  D  epartment  of 
D  efense  M  odeling  and  Simulation  M  aster  Plan  (available  at  http:/  /  www.dmso. 
mil)  requires  a  distributed  virtual  environment  (DVE)  wide  consistent  threat 
environment  to  achieve  a  useful  mission  rehearsal,  training,  and  test  and  evalua¬ 
tion  capability.  One  of  the  obstacles  to  achieving  large-scale,  complex  distrib¬ 
uted  virtual  environments  isthe  difficulty  and  expense  involved  in  inserting 
large  numbers  of  believable  actors  into  the  D  VE .  H  uman-controlled  actors  are 
costly  in  terms  of  both  hardware  and  human  time  due  to  the  large  numbers  of 
human  operators  required  to  control  actors  in  the  DVE  at  run-time.  However, 
little  relief  to  these  problems  has  been  forthcoming.  To  date,  computer-gener¬ 
ated  actor  (CG  A)  systems  have  proven  to  be  expensive  to  implement,  expensive 
and  challenging  to  modify,  and  lacking  in  realistic  behaviors.  Because  the  De¬ 
partment  of  D  efense  is  moving  toward  the  use  of  D  istri buted  M  ission  T raining 
(DMT)  for  aircrew  training,  approaches  to  mitigate  the  costs  associated  with 
current  CGA  implementations  are  needed.  A  more-flexible  CGA  architecture 
designed  for  training  needs,  cost  containment,  and  software  modification  is 
needed.  For  CGAs  to  be  useful  in  training,  they  must  exhibit  a  broad  range  of 
skills,  display  competency  and  realism  in  their  behaviors,  and  comply  with  cur¬ 
rent  doctrine.  To  minimize  costs,  a  single  computer  host  should  insert  a  num¬ 
ber  of  C  G  As  of  various  types  into  the  environment  and  coordinate  the  activities 
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of  its  own  actors  with  the  CG  As  that  are  controlled  by 
other  computer  hosts.  Because  of  the  rapid  rate  of 
changein  DVE  technologies  and  the  ever-expanding  set 
of  performance  objectives  for  any  CG  A,  the  system  must 
be  modifiable  at  reasonable  cost.  To  address  these  needs, 
we  undertook  the  development  of  a  CGA  application  for 
distributed  mission  training  threat  systems.  Because  of 
our  ready  access  to  military  DVEs,  wechoseto  develop 
and  refine  our  concepts  within  military  DVEs  that  are 
geared  toward  Air  Force  aircrew  DMT  needs. 

In  a  DVE  that  uses  CGA  systems  to  provide  threats 
for  aircrew  training,  each  of  theCGAsmust  exhibit  real¬ 
istic  levels  of  fidelity  to  all  the  other  actors  operating  in 
the  DVE,  and  they  must  also  interact  with  human-oper¬ 
ated  and  computer-controlled  actors  in  a  realistic  fash¬ 
ion.  Achieving  these  goals  using  current  systemsfor  Air 
Force  aircrew  training  in  DVE  sis  not  currently  possible 
for  two  reasons.  First,  each  manufacturer  of  primary  air¬ 
craft  simulator  training  systems  has  devised  a  simulator- 
specific  threat  system  and  made  modeling  decisions  that 
generally  support  only  a  specific  customer  organization 
for  a  select  few  predetermined  threats.  This  traditional 
threat  simulation  approach  is  expensive  and  leads  to  on¬ 
going  difficulties  in  maintaining  threat  currency  as  intel¬ 
ligence  updates  are  made,  new  weapons  are  introduced, 
and  new  theaters  of  operation  are  identified.  These 
simulator-specific  systems  tend  to  be  brittle  and  unmain¬ 
tainable  and  cannot  be  used  in  a  military  training  DVE 
without  substantial  investment  in  software  development. 
Second,  the  threat-system  interaction  on  a  distributed 
network  must  be  coordinated,  but  the  individualized 
nature  of  current  threat  systems  precludes  the  possibility 
of  introducing  coordinated  threats.  0  ur  work,  the  D  is- 
tributed  M  ission  Training  Integrated  Threat  Environ¬ 
ment  (D  M  TITE)  project,  was  undertaken  to  address 
these  two  issues. 

The  D  M  TITE  project  is  identifying  the  requirements 
for  a  distributed-threat  environment  and  building  a 
demonstrator  U  nited  States  D  epartment  of  D  efense 
(DoD)  FI  igh-Level  Architecture  (FI  LA)  compatible  sys¬ 
tem  to  provide  realistic  threats  for  aircrew  training.  The 
D  M  TITE  system  will  be  used  within  large-scale,  FI  LA- 
based  DVEs  to  insert  a  variety  of  accurate  and  highly 
realistic  threats  into  the  DVE  for  aircrew  training.  To  be 


a  suitable  system,  DM  TITE  must  provide  a  distributed- 
threat  environment  comprised  of  surface  threats,  air 
threats,  and  jamming  systems.  To  achieve  these  objec¬ 
tives,  DM  TITE  must  have  threat  models  and  knowledge 
bases  for  interaction  with  every  appropriate  entity  in  the 
DVE.  A  key  element  of  the  system  isthe  provision  of 
realistic  behaviors  and  multiple  skill  levels  for  the  threat 
systems.  T o  further  improve  the  fidelity  of  the  threat 
portrayal,  we  incorporate  realistic  sensor  models,  aero¬ 
dynamics  models,  and  weapons  models  into  DM  TITE 
for  each  threat  system.  Decision  making  can  be  accom¬ 
plished  using  a  variety  of  decision-making  techniques 
such  as  fuzzy  logic  or  case-based  reasoning.  Each 
DM  TITE  system  must  operate  autonomously  and  also 
be  able  to  cooperate  with  other  D  M  TITE  systemsfor 
the  DVE  to  portray  a  coordinated  threat  environment. 
Figure  1  illustrates  the  anticipated  way  in  which 
D  M  TITE  will  be  used. 

Asshown  in  Figure  1,  three  locations  (Eglin,  Luke, 
and  T yndall  Air  Force  Bases)  are  participating  within  this 
DVE.  Each  location  has  two  dedicated  DM  TITE  sys¬ 
tems  that  are  used  to  insert  threats  into  the  DVE .  Four 
manned  aircraft  trainer  systemsfor  aircrew  training  are 
colocated  with  the  D  M  TITE  systems  at  each  base.  T  wo 
additional  DMTITE  systems  in  the  DVE  are  responsible 
for  inserting  RADAR  threats  and  RADAR  jamming  into 
the  DVE.  Each  D  M  TITE  can  insert  a  variety  of  threat 
systems  into  the  DVE,  and  the  performance  of  each 
DMTITE  system  can  be  varied  to  portray  a  variety  of 
operator  skills  and  tactics. 

To  help  us  achieve  the  requirements  mentioned  above 
and  to  aid  us  in  developing  the  prototype,  we  devised 
and  refined  a  software  architecture  for  D  M  TITE  that 
naturally  supports  variety  in  performance  for  a  given 
typeof  CGA  and  also  allows usto  organizeand  build 
vastly  different  CG  As  within  the  same  architecture.  The 
architecture  also  had  to  help  us  uncover  and  refine  sys¬ 
tem  requirements  as  well.  Because  the  requirements  for 
DMTITE  expanded  over  the  course  of  the  project  and 
because  CGA  requirements  in  general  are  continuously 
changing,  an  evolutionary  and  exploratory  approach  to 
knowledge  engineering,  such  as  the  Rapid  Evolutionary 
and  Exploratory  Prototyping  (REEP)  methodology 
(Stytz,  Adams,  Garcia,  Sheasby,  &  Zurita,  1997)  isre- 
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quired.  To  support  the  REEP  approach,  our  architecture 
consists  of  highly  modular  components  in  which  inter¬ 
dependencies  are  well  defined  and  minimized. 

T  he  next  section  presents  a  short  discussion  of  back¬ 
ground  information  for  our  project.  Section  3  contains  a 
description  of  the  operational  concept  for  the  D  MUTE 
system,  its  requirements,  and  the  architectural  implica¬ 
tions  of  these  requirements.  Section  4  presents  the  simu¬ 
lation  object  model  we  developed  for  D  M  TITE.  Section 
5  contains  a  discussion  of  our  use  of  containerization  in 
D  M  TITE .  Section  6  presents  our  architectural  solution 
to  the  system  requirements  that  have  been  levied  against 


DM  TITE.  Section  7  presents  the  system  design.  Section 
8  contains  a  summary  and  presents  some  suggestions  for 
additional  work. 


2  Background 

Thissection  discusses DVEs,  CGAs,  relevant 
projects,  the  DoD  H  LA,  the  Common  Object  DataBase 
(CO  D  B)  baseline  for  the  D  M  TITE  system  architecture, 
and  the  REEP  approach  to  system  development.  These 
topics  form  the  groundwork  for  the  DM  TITE  architec- 
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tureand  its  operational  environment.  Before  turning  to 
these  topics,  we  will  first  define  our  terms.  In  aDVE,  an 
entity  is  a  component  of  a  D  VE  whose  state  can  change. 
For  example,  terrain  whose  appearance  and  features  can 
be  changed  as  a  result  of  plowing,  explosions,  or  traffic  is 
an  entity.  T errain  that  does  not  change  is  not  an  entity. 

An  actor  is  an  entity  that  moves  with  apparent  intelligent 
purpose.  Actors  can  be  virtual  (human  controlled),  con¬ 
structive  (traditional  simulation  controlled),  live  (de¬ 
rived  from  instrumented  range  data),  or  computer  gen¬ 
erated  (controlled  by  a  computer  program,  which  may 
include  artificial  intelligence  techniques).  In  a  DVE, 
weather  is  not  an  actor,  but  a  human-controlled  aircraft 
avatar  is  an  actor.  A  host  is  a  computer  system  within  a 
DVE  that  allows  its  human  or  computer  user  to  control 
actors  or  entities  within  the  DVE  and/  or  to  observe  the 
actions  of  other  virtual  environment  actors.  H  uman  be¬ 
havior  modeling  is  the  process  of  making  CGA  behaviors 
realistic  by  developing  models  of  the  output  of  the  hu¬ 
man  decision  process.  The  most  important  aspects  of 
developing  the  behavioral  model  for  a  CGA  are  knowl¬ 
edge  acquisition,  which  is  acquiring  the  information 
needed  to  effectively  model  human  behavior  within  the 
DVE;  knowledge  represen  tati  on ,  which  isputting  the 
knowledge  base  into  a  form  that  can  be  accessed  readily 
and  used  for  analysis  and  decision  making  during  DVE 
operation;  and  building  the  dedaon  making  apparatus 
to  perform  decision  making.  Knowledge  acquisition  and 
knowledge  representation  jointly  determine  the  infor¬ 
mation  about  the  human  mental  modelsthat  is  brought 
to  bear  on  the  CGA  decision  process. 

Distributed  Virtual  Environments:  The  most 
widespread  useof  network  technology  for  DVEsrelies 
upon  the  current  distributed  interactive  simulation 
(DIS)  suite  of  standards  (IE  EE  Standard  1278-1993)  or 
upon  the  H  LA.  D I S  was  designed  to  link  distributed, 
autonomous  hosts  into  a  real-time  DVE  via  a  network 
for  data  exchange.  The  data  describe  events  and  activi¬ 
ties.  D I S  takes  the  concept  of  environmental  distribution 
to  its  extreme;  there  is  no  central  computer,  event  sched¬ 
uler,  clock,  or  conflict  arbitration  system.  The  H  LA  isa 
more  comprehensive  architectural  approach:  it  describes 
the  communication  requirements,  basic  system  require¬ 


ments,  and  defines  an  object-oriented  approach  to  defin¬ 
ing  aDVE.  Stytz,  Banks,  and  Santos  (1996)  present  ad¬ 
ditional  information  concerning  D  IS  and  DVEs,  asdoes 
Blau,  H  ughes,  M  oshell,  and  Lisle  (1992)  and  Blau, 

M  oshell,  and  M  cDonald  (1993). 

The  H igh-level  Architecture:  B ecause  of  the 
difficulties  encountered  when  attempting  to  reuse  simu¬ 
lation  software  and  to  engineer  participants  for  a  DVE, 
the  U  S  D  epartment  of  D  efense  has  undertaken  develop¬ 
ment  of  a  H  igh-Level  Architecture  (H  LA)  for  DVE  ap¬ 
plications.  A  central  goal  of  the  H  LA  is  to  establish  a 
framework  that  facilitates  interoperability  between  simu¬ 
lations  and  models.  A  central  architectural  decision  sup¬ 
porting  this  goal  is  the  separation  of  application  func¬ 
tions  from  communications  functions.  All  application 
functions  are  managed  by  the  host  application  software 
system  while  communicationsfunctions are  managed  by 
the  run-time  infrastructure  (RT I ).  The  RTI  manages 
communication  paths  among  executing  applications  and 
ensures  that  its  application  acquires  the  data  that  it  needs 
and  can  make  available  to  the  DVE .  The  data  that  an 
actor  needsfrom  other  actors  in  the  DVE  isidentified  by 
subscribing  to  the  actors  that  can  provide  the  data.  The 
data  that  an  actor  provides  to  participants  is  published  to 
the  DVE,  and  actors  can  subscribe  only  to  data  that  has 
been  published.  The  RTI  publish-and-subscribe  mecha¬ 
nism  minimizes  theamount  of  data  transmitted  between 
applications  to  only  the  data  that  isrequired  by  the  ap¬ 
plications.  The  foundational  papers  for  H  LA  are  in  the 
15th  Workdiop  on  Standardsfor  thel  n  ter  operability  of 
Distributed  Si  mutations  (Calvin  &  Weatherly,  1996; 
Dahman,  Ponikvar,  &  Lutz,  1996;  Fujimoto  &  Weath¬ 
erly,  1996;  M  iller,  1996;  and  Stark,  Weatherly,  &  Wil¬ 
son,  1996). 

One  aspect  of  achieving  FI  LA  compliance  for  an  appli¬ 
cation  is  the  construction  of  its  simulation  object  model 
(SOM  ).  The  SOM  ,  in  conjunction  with  the  federation 
object  model  (FOM  )  for  a  simulation  exercise  (federa¬ 
tion),  specifies  the  object  model  template  (0  M  T)  re¬ 
quired  by  all  participants  in  a  federation.  The  SOM  is 
used  to  document  key  information  about  the  software 
for  generating  an  entity,  such  as  thetypesof  entities  sup¬ 
ported,  the  information  that  each  entity  can  export  to 
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the  D  VE,  the  information  each  entity  requires  from  the 
DVE,  and  the  types  of  interactions  that  each  entity  can 
participate  in.  The  SO  M  also  documents  the  informa¬ 
tion  that  an  actor  or  actor  superclass  in  an  application 
requires  to  operate.  This  information  isobtained  by  sub¬ 
scribing  to  remote  actors  in  theDVE.  Finally,  the  SOM 
documents  the  information  that  each  actor  and  actor 
class  can  provide  to  a  DVE  and  therefore  can  publish. 

I  nformation  is  made  available  by  subscription  and  publi¬ 
cation.  Other  DVE  actors  can  subscribe  to  classesorto 
class  types  in  the  application.  By  subscribing  to  a  class, 
an  actor  is  guaranteed  that  it  will  receive  all  updates  for 
all  of  the  data  values  for  the  subscribed  class.  A  publish¬ 
able  class  is  a  class  that  is  instantiated  within  the  applica¬ 
tion  and  that  will  make  certain  information  about  itself 
availableto  other  actors  within  the  DVE .  Subscription 
can  take  place  at  the  class,  superclass,  or  subclass  levels. 
For  superclasses,  information  is  only  subscribable.  Sub¬ 
classes  can  publish  and  subscribe  to  information.  The 
su  be  I  asses  are  ref  i  n  em  en  ts  o  f  t  h  ei  r  su  perc  I  asses  an  d  i  n  - 
herit  properties  from  them  and  also  expand  upon  their 
properties  as  well.  0  nly  single  inheritance  is  supported 
within  a  SOM  class  structure.  The  specification  of  a 
SOM  for  a  system  requires  the  definition  of  an  object 
class  structure  table,  an  interaction  class  structure  table, 
an  attribute  table,  and  a  parameter  table. 

T  he  object  class  structure  table  in  the  SO  M  defines 
the  classes  of  DVE  actors  that  a  simulation  application 
can  support  and  the  remote  DVE  actor  classes  whose 
instances  and  attributes  represent  potentially  useful  in¬ 
formation  to  the  simulation  application's  local  actors. 
These  classes  of  local  and  remote  actors  are  defined  by 
specifying  the  hierarchical  relationships  among  the  vari¬ 
ous  classes  in  the  FI  LA  application.  The  object  class 
structure  table  specifies  the  classes  of  C  G  As  that  the  ap¬ 
plication  will  support  and  interact  with,  such  as  aircraft, 
missiles,  etc.,  as  well  as  the  specific  instances  of  each  type 
of  class  that  are  available,  such  as  a  F-15  fighter,  Sparrow 
missile,  etc.  I  n  this  table,  the  application  designer  deter¬ 
mines  the  actors  that  the  application  can  make  available 
and  requires  in  any  DVE  in  which  it  participates. 

The  second  table  required  in  a  SO  M  isthe  interaction 
class  structure  table.  In  a  SOM  ,  an  interaction  is  defined 
as  an  action  that  an  actor  can  perform  that  can  poten¬ 


tially  have  some  effect  on  another  actor  in  the  DVE .  The 
interaction  class  structure  table  specifies  the  types  of  in¬ 
teractions  in  which  each  actor  can  participate.  As  in  the 
object  class  structure  table,  the  interactions  are  described 
hierarchically,  thereby  enabling  inheritance  to  be  used  to 
specify  interactionsthat  are  common  to  whole  classes  of 
actors.  An  important  specification  in  the  table  isthe  in¬ 
teraction  type  supported  by  each  interaction  class.  Each 
interaction  can  be  one  that  an  actor  in  D  M  TITE  can 
initiate,  sense,  react  to,  or  ignore.  An  actor  can  initiate 
an  interaction  if  it  has  the  capability  to  model  the  initia¬ 
tion  of  the  interaction  and  can  also  call  the  FI  LA  send- 
interaction  service  for  the  interaction  when  it  is  initiated. 
An  actor  can  sense  an  interaction  if  it  is  capable  of  utiliz¬ 
ing  information  about  received  interactions.  An  actor 
can  react  to  an  interaction  if  it  has  the  capability  of  pub¬ 
lishing  those  of  its  attributes  that  have  been  affected  by 
an  interaction  and  also  updating  these  same  attributes 
internally. 

Thethird  table  required  byaSOM  isthe  attribute 
table.  I  n  the  SO  M  ,  an  attribute  is  a  named  portion  of  a 
class  of  actor's  state  whose  values  may  change  over  time. 
The  attribute  table  documents  the  data  produced  and 
consumed  by  each  classof  actor  in  the  application.  The 
individual  actor  attributes  defined  in  this  table  can  be 
subscribed  to  by  an  actor  in  a  remote  host  or  published 
to  the  rest  of  the  DVE  by  a  local  actor.  By  subscribing  to 
a  class  or  subclass,  a  remote  actor  that  requires  only  a 
limited  subset  of  information  for  an  actor  will  receive 
only  the  information  that  it  requires,  thereby  conserving 
network  bandwidth  and  processing  power.  Conversely, 
by  specifying  only  the  information  that  the  actor  re¬ 
quires  to  function,  network  bandwidth  and  remote-host 
processing  isconserved  because  unneeded  information  is 
not  generated  or  transmitted.  The  attribute  table  in  a 
SO  M  defines  the  attributes  for  each  of  the  classes  in  the 
DVE  application.  Updates  to  these  attributes  are  the 
data  that  actually  flows  among  the  actors  that  compose  a 
DVE.  To  specify  the  attributes  for  a  class,  the  name  of 
the  object  class  for  the  data  item  must  be  specified  (us¬ 
ing  the  same  name  for  the  class  that  was  defined  in  the 
object  class  structure  table).  I  n  addition,  the  name  of 
each  attribute  for  the  class,  its  data  type,  the  cardinality 
of  the  datatype  (if  it  is  an  array),  and  the  units  of  mea- 
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sure  for  the  data  are  also  specified.  The  resolution  and 
accuracy  for  the  attributes  specify  how  accurate  the  data 
must  be.  The  resolution  of  an  attribute  is  defined  to  be 
the  attribute's  maximum  deviation  from  its  true  value 
(value  at  its  generating  host)  that  is  permitted  through¬ 
out  the  DVE.  Accuracy  is  defined  to  be  the  condition 
required  to  be  satisfied  for  the  resolution  requirement  to 
be  met.  Additional  information  such  as  the  data  update 
type  and  update  condition  are  also  specified,  these  com¬ 
ponents  of  the  table  determine  if  an  update  to  the  data  is 
possible,  and  if  so  under  what  conditions.  The  attributes 
for  the  classes  are  defined  hierarchically  and  datatypes 
from  superclasses  are  inherited  by  the  specified  sub¬ 
classes. 

The  fourth,  and  final,  table  required  in  an  H  LA  SO  M 
is  the  interaction  parameters  table.  The  interaction  pa¬ 
rameters  table  is  based  upon  the  information  contained 
in  the  interaction  class  structure  table  and  the  attribute 
table.  The  interaction  typesdefined  in  the  interaction 
class  structure  table  are  the  basis  for  the  interaction  pa¬ 
rameters  table  as  it  determines  the  specific  interactions 
to  be  supported  for  each  class  and  superclass  in  an  appli¬ 
cation.  The  attribute  table,  on  the  other  hand,  contains 
the  list  of  available  parameters  that  can  be  supplied  by  an 
actor  class  or  subclass  for  any  interaction.  The  interac¬ 
tion  parameters  table  presents  each  generic  interaction 
and  specific  interaction  that  is  required  to  be  supported 
by  the  application. 

Computer-generated  Actors:  C  omputer-gener- 
ated  actors  (CG  As)  that  exhibit  believable  humanlike 
behaviors  are  crucial  to  achieving  large-scale  DVE  s.  Ap¬ 
proaches  to  achieving  realistic  CG  As  are  described  by 
C alder,  Smith,  Courtemanche,  M  ar,  and  Ceranowicz, 
1993;  Edwards  and  Stytz,  1996;  Laird,  N  ewell,  and 
Rosenbloom,  1987, 1995;  and  T ambe,  J  ohnson,  J  ones, 
Koss,  Laird,  Rosenbloom,  and  Schwamb,  1995.  The 
run-time  challenges  foraCGA  arise  from  the  need  to 
compute  humanlike  behaviors  and  reactions  to  a  com¬ 
plex  dynamic  environment  at  a  human-scale  rate  of  time. 
H  owever,  the  computational  challenge  is  eased  some¬ 
what  because  there  is  no  need  to  replicate  the  human 
decision  process;  instead,  only  the  observable  aspects  of 
human  decision  making  must  be  mimicked.  I  n  addition, 


the  CGA's  behavior  must  be  realistic  and  accurate 
enough  so  that  other  CG  As  and  human  participants  re¬ 
act  to  its  behaviors  as  though  the  CGA's  avatar  were  hu¬ 
man-controlled. 

For  our  purposes,  the  major  components  of  a  C  G  A 
are  vehicle  dynamics,  behavior  modeling,  artificial  intelli¬ 
gence,  and  software  architecture.  Vehicle  dynamics  are 
important  because  the  actor  should  move  through  the 
virtual  environment  accurately  whether  the  CG  A  is  hu¬ 
man  or  computer  controlled.  The  vehicle  dynamics  for 
computer-controlled  actors  should  never  allow  a  human 
to  identify  it  as  a  CGA.  H  uman-behavior  modeling  re¬ 
quires  the  acquisition  of  domain-specific  knowledge 
about  the  domain  models  that  humans  use  and  about 
the  information  that  humans  use  in  the  decision-making 
process.  ForaCGA  in  a  military  virtual  environment, 
human-behavior  modeling  requires  incorporating  doc¬ 
trine,  tactics,  knowledge  models,  and  training  into  the 
CGA. 

Artificial  intelligence  addresses  the  problems  associ¬ 
ated  with  assessing  and  reacting  to  the  environment 
based  upon  considerations  like  plans,  assigned  mission, 
the  activities  of  other  actors,  the  available  domain 
knowledge,  and  the  capabilities  of  the  vehicle  that  the 
CGA  must  control.  The  artificial  intelligence  component 
ensuresthattheCGA  pursues  its  goals,  respondsin  a 
proper,  humanlike  manner  based  upon  its  knowledge 
base,  develops  plans  based  upon  its  knowledge  base,  and 
manages  other  tasks.  The  vehicle  dynamics,  behavior 
modeling,  and  artificial  intelligence  system  components 
are  brought  together  within  the  CGA  software  architec¬ 
ture  component.  A  flexible  CGA  software  architecture 
ensures  extensibility  to  meet  future  CGA  requirements. 

Common  O  bject  DataBase  and  Rapid 
Exploratory  and  Evolutionary  Prototyping:  The 

DMTITE  architecture  is  based  upon  the  common  object 
database  (CO  D  B)  architecture  described  by  Stytz  et  al. 
(1997).  The  common  object  database  is  a  data-handling 
architecture  that  uses  object  classes,  containerization, 
and  a  central  run-time  data  repository  to  manage  and 
route  data  among  the  major  objects  in  an  DVE  applica¬ 
tion.  The  CO  D  B  holds  the  entire  current  state  of  the 
DVE  and  all  the  public  information  for  each  threat  in 
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operation  within  theDMTITE  application.  TheCODB 
architecture  reduces  the  coupling  in  an  application's 
software  by  reducing  the  amount  of  information  that  a 
class  must  maintain  about  other  classes;  all  of  the  data 
that  an  entity  requires  to  interact  with  the  D  VE  is  lo¬ 
cated  in  the  COD  B,  and  all  of  the  data  an  entity  must 
export  is  placed  in  theCOD  B.  To  acquire  public  data 
from  other  D  M  THE  application  objects,  an  object  need 
only  access  the  container  in  the  CO  D  B  where  the  infor¬ 
mation  resides.  The  world  state  manager  (WSM  )  portion 
of  the  CO  DB  handles  incoming  and  outgoing  network 
traffic  from  a  simulation  application  and  also  maintains 
the  world  state  for  all  entities  controlled  outside  of  its 
host. 

The  rapid  exploratory  and  evolutionary  prototyping 
(REEP)  methodology  (Stytz  et  al . ,  1997),  is  a  method¬ 
ology  that  supports  quick  extraction  and  refinement  of 
requirements,  experimentation  with  alternative  means 
for  satisfying  requirements,  and  rapid  incorporation  into 
the  application  of  the  solutions  developed  by  successful 
experiments.  Exploratory  prototyping  examines  an 
implementation  solution  within  the  context  of  an  opera¬ 
tional  solution,  and  significantly  accelerates  the  ability  to 
assess  alternative  implementation  solutions.  The  intent 
of  evolutionary  prototyping  is  to  allow  successive  revi¬ 
sions  to  the  overall  design  and  implementation  without 
making  major  modifications  to  the  system.  The  REE  P 
process  begins  with  the  construction  of  an  initial  proto¬ 
type  of  the  application  to  satisfy  baseline  requirements. 

Baseline  DMTITE  Architecture:  The  starting 
pointfortheDMTITE  architecture,  shown  in  F igure 2, 
is  the  common  object  database  (CO  D  B).  This  architec¬ 
ture  was  developed  to  support  the  operation  of  a  single 
CGA  inaDVE.  In  this  architecture,  the  CO  D  B,  as  a 
run-time  data  repository,  is  used  to  manage  data  transfer 
between  the  D  VE  and  a  single  actor  in  DMTITE.  I  n  the 
baseline  architecture,  the  network  interface  and  network 
component  is  responsible  for  the  transmission  of  infor¬ 
mation  between  DMTITE  and  the  other  computers  that 
are  instantiating  the  D  VE .  Aseach  D I S  protocol  data 
unit  (PD  U  )  arrives,  it  is  forwarded  from  the  network 
interface  software  to  theWSM  .  The  WSM  is  responsible 


for  maintaining  the  state  of  the  entire  DVE.  Therefore, 
theWSM  takes  incoming  data,  updates  its  information 
about  the  entity,  and  places  the  information  in  the  con¬ 
tainer  for  transmission  to  the  CO  D  B.  In  addition,  the 
WSM  is  responsible  for  dead  reckoning  entities  inbe- 
tween  receipt  of  data  for  the  entity.  Asa  result,  when  the 
CO  D  B  requests  an  update  to  its  information  from  the 
WSM  ,  theWSM  has  a  container  holding  the  most-cur- 
rent  information  about  the  state  of  the  DVE  ready  to  be 
dispatched. 

0  nee  in  the  CO  D  B,  the  data  is  made  available  to  the 
actor's  decision-making  system,  dynamics  unit,  and  sen¬ 
sors.  The  dynamics  unit  and  sensors  components  share  a 
container  to  minimize  the  amount  of  data  to  be  trans¬ 
ported,  and  together  comprise  the  physical  dynamics 
component  (PDC).  The  PDC  contains  the  description 
of  all  of  the  physical  attributes  and  properties  of  the  indi¬ 
vidual  CGA.  In  addition  to  the  dynamics  unit  and  sen¬ 
sors,  in  the  baseline  architecture  the  PDC  component 
includes  the  actor-specific  properties,  performance  capa¬ 
bilities,  weapons  load,  damage  assessment,  and  physical 
status.  The  PDC  also  computes  physical  state  changes. 
For  example,  the  dynamics  unit  uses  the  information  in 
the  CO  DB  to  compute  the  current  velocity  and  orienta¬ 
tion  of  the  actor,  and  places  the  results  of  its  computa¬ 
tions  back  into  the  C  0  D  B  for  use  by  the  decision-mak¬ 
ing  system  and  for  transmission  to  the  rest  of  the  DVE. 
The  sensors  component  uses  the  information  to  deter¬ 
mine  the  actors  that  are  within  range  of  the  actor's  sen¬ 
sor  systems  and  places  the  result  into  theCOD  B  for  use 
by  the  decision-making  system. 

The  decision-making  system  for  the  baseline  architec¬ 
ture  consisted  of  two  components  (Figure  2):  a  skills 
component  (SC)  and  the  active  decisions  component 
(ADC).  TheSC  consists  of  those  portions  of  the  CGF 
(computer-generated  force)  that  vary  between  individual 
entities  within  a  type  and  class.  This  component  serves 
to  model  the  skills  and  ability  of  the  operator  of  an  en¬ 
tity.  The  ADC  contains  the  intelligent  decision-making 
processes  and  the  knowledge  required  to  drive  them. 
The  knowledge  includes  the  overall  mission,  goalsand 
objectives,  plan  generation,  reaction  time,  and  crisis- 
management  ability.  I  n  the  baseline  architecture,  the 
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Figure  2.  Baseline  distributed  training  system  application  architecture  showing  the  major  architectural 
system  components. 


ADC  has  three  reasoning  engines:  the  strategic  decision 
engine  (SDE),  tactical  decision  engine  (TDE),  and  the 
critical  decision  engine  (CDE).  These  engines  perform 
long-term,  near-term,  and  immediate-reasoning  opera- 
tionsfortheCGA,  respectively.  Thesedecision  engines 
(DEs)  are  described  further  in  Stytzetal.  (1996). 

We  separated  the  PDC,  SC,  and  ADC  components 
from  the  remainder  of  the  CGF  architecture  and  from 
each  other  to  ensure  that  modifications  to  a  component 
is  isolated  to  the  component  and  do  not  propagate 
throughout  the  entire  system.  The  PDC  is  only  respon¬ 
sible  for  the  basic  entity  maneuver  and  sensing  computa¬ 
tions,  and  functions  completely  unaware  of  the  status  of 
the  other  system  components.  Likewise,  the  ADC  is 
solely  responsible  for  decision  making  and  only  knows 


about  the  physical  component's  status  based  upon  the 
data  communicated  to  it  via  the  CO  D  B.  In  the  baseline 
architecture,  the  SC  is  more  closely  tied  to  the  ADC 
thanthePDC  because  theADC  is  responsible  for  com¬ 
puting  control  outputs  for  the  entity  based  upon  the 
modeled  pilot's  skills.  The  SC  describes  the  pilot's  ability 
to  the  decision-making  component  so  that  the  decision 
can  be  appropriately  constrained  by  the  simulated  pilot's 
abilities. 

U  sing  the  information  described  above,  the  baseline 
architecture,  and  interviews  with  subject-matter  experts, 
we  defined  the  requirements  for  D  M  TITE  in  light  of  its 
concept  of  operations  and  the  objectives  for  the  applica¬ 
tion.  The  next  section  summarizes  the  results  of  this 
process. 
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3  DMTITE  Requirements  and  Their 
Implications 

As  a  prelude  to  describing  our  architectural  solu¬ 
tion  and  to  support  our  SOM  specifications  and  software 
design  decisions,  this  section  presents  a  discussion  of  the 
system  requirements  that  DMTITE  must  satisfy.  T o 
clarify  the  connection  between  these  requirements  and 
our  subsequent  architecture  and  design,  we  also  assess 
the  implications  of  the  requirements  for  the  D  M  T  IT  E 
software  and  knowledge-base  architectures. 

DMTITE  Requirements:  The  requirements  for 
DMTITE  can  be  divided  into  several  categories.  These 
categories  were  derived  from  those  used  to  specify  the 
requirementsforaircraftCGAsby  Stytz,  Banks,  and 
Santos  (1996).  These  requirements  range  from  the  soft¬ 
ware  architecture  that  implements  theCGA  to  the 
knowledge  base  used  by  theCGA  to  support  its  decision 
making.  The  origin  of  these  requirements  lies  in  the 
need  to  support  a  wide  variety  of  aircrew  training  sce¬ 
narios  while  also  using  a  credible  representation  of  the 
behavior  for  each  modeled  entity.  Briefly,  DMTITE 
should  possess  the  capability  to  perform  thefollowing 
tasks. 

1)  hosting  a  wide  variety  of  threat  systems,  such  as 
anti-aircraft  artillery  (AAA),  surface-to-air  missiles 
(SAM  s),  jamming  radars,  acquisition  radars,  sound 
and  infrared  DVE  actors  systems,  aircraft,  and  un¬ 
manned  autonomous  vehicles  (U  AVs), 

2)  ease  of  modifiability  for  its  knowledge  bases,  deci¬ 
sion-making  systems,  and  networking  services, 

3)  versatile  decision  mechanisms  and  modifiable  actor 
behaviors, 

4)  hardware  independence, 

5)  exterior  (commercial)  software  independence, 

6)  a  variety  of  threats  at  varying  levels  of  fidelity  de¬ 
termined  by  the  training  scenario  being  executed, 

7)  a  variety  of  skills  leveisfor  each  actor  type  for  rea¬ 
soning  capabilities  and  performance  skills, 

8)  terrain  reasoning  capability  as  part  of  operator 
emulation, 

9)  accurate  modeling  of  real-world  sensor  outputs, 


10)  H  LA  compliance,  and 

11)  capability  to  download  scenariosfrom  other 
DMTITE  locationsand  reuse  them. 

The  next  few  paragraphs  delve  into  a  select  few  of 
these  requirements  and  assess  their  implications  for  the 
DMTITE  project. 

A  variety  of  threat  s/stems  For  the  D  M  TITE  to 
achieve  its  objective  for  operational  training,  it  must  be 
capable  of  inserting  a  variety  of  threat  systems  into  the 
D  V  E .  0  ne  project  goal  is  to  separate  the  threat  systems 
from  the  pilot  training  system  and  to  distribute  them 
across  the  network;  therefore,  every  threat  system  must 
have  at  least  a  generic  representative  within  DMTITE. 

M  odifi ability:  M  odifiability  isthe  ability  to  en¬ 
hance  existing  CGA  capabilities  as  well  as  perform  soft¬ 
ware  maintenance.  Thiscapability  includes  the  need  to 
rapidly  expand  a  domain-specific  knowledge  base,  the 
use  of  a  flexible  software  architecture,  the  capability  to 
operate  on  a  variety  of  hardware,  and  independence 
from  external  software.  The  requirement  for  knowledge¬ 
base  expandability  addresses  the  need  for  the  CGA  to 
incorporate  new  strategies,  tactics,  and  maneuvers  as  ally 
and  opponent  concepts  change.  T  he  need  for  modifi¬ 
ability  also  addresses  the  need  to  maintain  DMTITE  in 
the  field  and  supports  improvement  of  the  system's  op¬ 
eration  by  permitting  well-encapsulated  changes  to  the 
knowledge  base.  A  flexible  software  architecture  likewise 
assists  in  readily  adapting  DMTITE  to  meet  new  perfor¬ 
mance,  interface,  and  communication  protocol  require¬ 
ments.  H  ardware  independence  addresses  the  need  to  be 
able  to  port  DMTITE  to  more-capable  computer  hard¬ 
ware  with  minimum  changes  to  the  system's  code.  The 
need  to  remain  independent  from  commercial,  non- 
DMTITE  software  supports  the  need  to  remain  inde¬ 
pendent  of  hardware  and  allows  the  system  to  take  ad¬ 
vantage  of  developments  that  can  improve  its 
performance. 

H  igh  fidelity  representations  H  igh-fidelity  repre- 
sentationsin  DMTITE  are  achieved  byoperating  each 
CGA  using  accurate  world  representations  (especially 
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terrain),  dynamics  for  vehicle  motion,  sensor  and 
weapon  models,  and  models  of  human  behavior.  The 
world  representations  are  based  upon  surface  representa¬ 
tions  composed  from  primitive  data  elements  organized 
within  a  hierarchical  representation  of  the  terrain  data. 

H  owever,  because  CG  As  do  not  operate  in  isolation, 
their  world  representation  must  have  a  high-fidelity 
counterpart  for  manned  systems  as  well  as  for  other 
CGA  systems.  Correct  vehicle  dynamics  ensures  that  the 
D  VE  actor  only  moves  according  to  the  capabilities  of  its 
real-world  counterpart  and  does  not  exhibit  unrealistic 
performance  given  the  D  VE'sterrain,  weather,  and  at¬ 
mospheric  conditions.  Likewise,  the  weapons  and  sensor 
models  for  each  D  M  THE  actor  must  use  models  with 
the  same  sensitivity,  field  of  view,  and  range  as  used  by 
their  real-world  counterparts.  The  requirement  for  sen¬ 
sor  fidelity  exists  across  all  sensors,  from  the  eyesight  of 
theassumed  operator  of  the  CGA  to  the  radar  and  infra¬ 
red  sensing  systems  used  by  the  real-world  counterpart 
of  theCGA. 

A  daptable decision  mechanics  Adaptable  deci¬ 
sion  mechanisms  give  the  CGA  flexibility  in  dealing  with 
situations  that  occur  in  the  distributed  virtual  environ¬ 
ment.  Adaptable  decision  mechanisms  permit  the  system 
to  maintain  robust,  credible  behavior  for  D  M  TITE  ac¬ 
tors  under  a  variety  of  external  circumstances,  such  as 
missing  or  inconsistent  information,  and  at  different  lev¬ 
els  of  operator  skill.  This  requirement  ensures  that  each 
threat  instantiated  by  D  M  T I T  E  can  operate  effectively 
even  when  confronted  by  conflicting  or  incomplete  in¬ 
formation  and  when  under  system  stress. 

Threatsat  varying  le/elsof  fidelity  and  a  variety  of 
dcillslevels  The  first  component  of  this  requirement 
speaks  to  the  need  to  conserve  computational  power. 
Threat  actors  should  beableto  be  instantiated  at  mul¬ 
tiple  levels  of  fidelity  so  that  only  those  threats  that  re¬ 
quire  a  high-fidelity  representation  use  a  high-fidelity 
model  and  are  permitted  to  consume  a  correspondingly 
greater  amount  of  available  computational  resources. 
Regardless  of  the  level  of  fidelity,  each  threat  actor 
should  also  be  available  in  a  range  of  skill  levels.  M  ultiple 


skill  levels  allow  the  training  to  be  tailored  to  the  abilities 
of  the  human  participants  and  provide  a  more  realistic 
training  situation  because  the  opponents  and  allies  ex¬ 
hibit  a  variety  of  capabilities.  The  skills  can  be  realized  by 
varying  manual  skills,  by  varying  the  range  of  options 
available  to  the  decision-making  component,  by  varying 
the  knowledge  about  friendly  and  enemy  tactics  available 
to  the  decision-making  component,  and  by  permitting 
the  decision-making  component  to  forecast  the  impact 
of  each  available  option  on  its  ability  to  perform  its  mis¬ 
sion. 

Implications  of  these  requirements:  The  above 
requirements  have  implications  for  system  complexity, 
real-time  performance,  knowledge  engineering,  and 
scalability.  We  discuss  these  implications  below. 

The  requirement  to  beableto  instantiate  a  wide  vari¬ 
ety  of  threat  systems  within  a  single  computer  host  indi¬ 
cates  that  the  system  must  use  general-purpose  reason¬ 
ing  mechanisms  coupled  with  threat-specific  knowledge 
bases  for  reasoning  about  the  state  of  the  D  VE  and  the 
actors  within  it.  To  conserve  memory  and  minimize  data 
handling,  the  architecture  must  allow  the  instantiated 
threats  to  share  a  single,  shared  representation  of  the 
DVE  state,  permit  identical  entities  to  share  knowledge 
bases,  and  allow  each  threat  to  have  a  customizable, 
publish-and-subscribe  profile  for  its  interaction  with  the 
other  DVE  participants  regardless  of  whether  they  are 
local  or  remote. 

The  requirement  to  achieve  a  modifiable  system  indi¬ 
cates  that  the  system  should  be  structured  so  that  com¬ 
ponents  are  strictly  isolated  from  each  other  and  so  that 
there  is  loose  coupling  among  components  of  the  sys¬ 
tem.  By  ensuring  the  isolation  of  system  components, 
the  architecture  minimizes  the  impact  of  changes  to  the 
DM  TITE  application,  and  it  also  serves  to  retard  archi¬ 
tectural  entropy.  T  wo  central  consequences  of  the  goal 
of  achieving  isolation  and  minimizing  coupling  are  that 
data  movement  among  components  should  be  carefully 
managed  within  the  architecture  and  that  the  program¬ 
mer  should  be  constrained  to  remain  within  the  system's 
architectural  approach.  M  odifiability  can  complicate  the 
design  because  there  must  be  a  clean  separation  between 
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the  knowledge  representation  and  the  decision  mecha¬ 
nism. 

The  need  for  D  M  TITE  to  provide  high-fidelity  actor 
rep  resen  tat  i  o  n  s  affects  the  system '  s  arc  h  i  tect  u  re,  kn  o  w  I  - 
edge  base,  and  information  flows.  Because  we  require 
high-fidelity  actor  representations  but  must  also  con¬ 
serve  processing  power,  the  architecture  must  support 
multiple  levels  of  fidelity  in  the  representations  of  the 
DVE  terrain,  actor  vehicle  dynamics,  and  simulated  hu¬ 
man  behavior.  Additionally,  DMTITE  must  have  access 
to  different  levels  of  detail  of  information  so  that  the 
decision  engine  is  not  burdened  with  reasoning  about 
high-detail  information  that  is  beyond  its  sensor  range. 
The  data  flows  must  ensure  that  the  information  avail¬ 
able  to  the  decision-making  mechanisms  accurately 
models  the  type  and  quantity  of  information  that  the 
sensors  in  the  actual  vehicle  would  provide  to  a  human 
operator  in  the  real  world.  As  regards  the  knowledge 
base,  the  design  should  encapsulate  related  items  of 
knowledge  within  a  single  access  unit  and  ensure  the 
separation  of  unrelated  knowledge  components.  Encap¬ 
sulated  knowledge  permits  the  decision  mechanismsto 
atomically  access  the  information  they  require  and  also 
permits  the  designer  to  update  the  knowledge  bases  with 
minimal  impact  upon  other  information  in  the  knowl¬ 
edge  base. 

The  requirements  for  adaptability,  multiple  skill  levels, 
and  multiple  levels  of  fidelity  affect  several  aspectsofthe 
knowledge  base  and  the  decision-making  components. 
First,  the  decision-making  component  must  contend 
with  incomplete  information  and  uncertainty  about  the 
DVE  because  available  information  will  be  limited  to 
that  capable  of  being  provided  to  the  operator  in  the  real 
world.  The  decision  mechanism  must  be  structured  so 
that  the  amount  of  information  considered  when  mak¬ 
ing  the  decision  can  be  adaptively  varied  and  so  that  ad¬ 
ditional  possibilities  can  be  considered  as  time  and  cir¬ 
cumstances  permit.  Second,  because  the  system  requires 
general-purpose  decision  mechanisms,  the  knowledge¬ 
base  component  must  be  comprehensive  enough  to  al¬ 
low  the  decision  mechanism  to  satisfy  the  requirements 
for  multiple  skill  levels  and  multiple  levels  of  fidelity.  Fi¬ 
nally,  the  need  for  multiple  levels  of  fidelity  affects  the 
decision-making  component  in  that  one  means  of 


achieving  computational  savings  is  to  alter  the  type  of 
reasoning  performed.  Therefore,  the  decision-making 
component  of  the  D  M  TITE  architecture  must  support 
the  use  of  different  reasoning  systemsfor  a  given  threat 
without  requiring  changes  to  the  threat's  knowledge 
base. 

The  next  step  we  undertook  in  developing  DMTITE 
was  identification  of  the  required  inputs  and  outputs  for 
the  system  based  upon  thetypesof  interactions  that  each 
actor  had  to  support.  The  next  section  summarizes  the 
FI  LA-compliant  simulation  object  model  that  resulted. 

4  The  DMTITE  Simulation  Object  Model 

The  specification  of  the  simulation  object  model 
(SO  M  )  for  D  M  TITE  required  the  definition  of  an  ob¬ 
ject  class  structure  table,  an  interaction  class  structure 
table,  an  attribute  table,  and  a  parameter  table.  The  de¬ 
velopment  of  the  SO  M  is,  in  many  ways,  a  refinement  of 
the  requirements  identified  in  the  preceding  section. 

FI  owever,  in  the  preceding  section  requirements  were 
specified  as  high-level  objectives.  With  the  complete 
specification  of  the  SO  M  ,  many  of  the  interaction  re¬ 
quirements  and  the  fidelity  provided  by  the  system  are 
determined.  In  our  case,  since  we  were  developing  the 
system  from  scratch,  we  were  able  to  address  the  desired 
interactions  in  detail  and  to  use  this  specification  to 
guide  the  capabilities  developed  in  each  of  the  compo¬ 
nents  aswell  as  to  assist  in  determining  the  features  that 
the  D  M  TITE  architecture  should  exhibit. 

The  first  table  defined  for  D  M  TITE  was  the  object 
class  structure  table,  depicted  in  Table  1.  I  n  Table  1  and 
the  other  SO  M  tables,  the  items  in  the  farthest  lefthand 
column  are  the  superclasses  for  DMTITE;  the  subclasses 
of  a  class  are  below  and  to  the  right.  The  subclasses  are 
refinements  of  their  superclasses  and  inherit  properties 
and  subscription  and  publication  requirements  from 
them  and  can  also  expand  these  properties  as  well.  I  n 
Table  1,  we  specified  all  of  the  classes  of  actors  and  the 
subclassesof  actors  that  D  M  TITE  can  instantiate  for  an 
exercise.  For  example,  Table  1  shows  that  DMTITE  has 
a  superclass  called  AAA.  As  subclasses  of  the  AAA  class, 
two  additional  classes  are  defined:  the  generic  AAA  and 
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T able  I.  DM  TITE  Simulation  Object  Class  Structure  Table 


Class 

Type 

AAA 

generic  AAA 

ZSU-28  AAA 

SAM 

generic  SAM 

Radar 

generic  radar 
generic  fixed  radar 
generic  mobile  radar 

J  amming  radar 

generic  jamming  radar 

UAV 

generic  U  AV 

Aircraft 

generic  fighter  aircraft 
generic  bomber  aircraft 
generic  Wild  Weasel  aircraft 

M  issile 

generic  radar-guided  missile 
generic  infrared-guided  missile 
generic  laser-guided  missile 
generic  radar-homing  missile 

theZSU  -28.  Data  about  actors  in  both  of  these  sub¬ 
classes  can  be  accessed  by  other  actors  by  subscribing  to 
information  about  these  types  of  actors,  and,  when  in¬ 
stantiated,  these  D  M  TITE  actors  publish  information  to 
theDVE. 

The  object  class  structure  table  documents  the  types 
of  actors  that  are  available  within  D  M  TITE  and  the  pub- 
lish-and-subscribe,  information-transfer  relationships 
among  these  actors  and  the  remainder  of  the  actors  in 
the  D  VE .  These  information-transfer  relationships  are 
the  basis  for  the  information  documented  in  the  class 
attribute  table  defined  for  DM  TITE.  H  owever,  before 
the  class  attribute  table  can  be  defined,  the  interaction 
class  structure  table  must  be  specified. 

The  D  M  TITE  interaction  class  structure  table,  illus¬ 
trated  in  Table  2,  specifies  the  interactions  required  of 
each  DMTITE  actor.  Table2  contains  a  portion  of  the 


T able  2.  Abstract  of  the  Interaction  Class  Structure  Table 
for  the  DMTITE  Simulation  Object  M  odel 

I  nteraction  I  nteraction  class  I  nteraction  type 

radar_ 

broadcast 

friend  I  y_radar- 
_b road  cast 

initiate  friend ly- 
_broadcast 
friendly_broadcast- 
_state_update 
terminate  friendly- 
broadcast 

air-to-ground 

attack 

opponentmissile- 

_attack 

opp_missile_launch 

opp_missile_st6ite 

opp_missile_de- 
coys_deploy 
o  pp_m  issi  I  ej  impact 
&  detonate 

opponent_ 

rocket_attack 

opp_rocket_launch 

opp_rocket_state 

opp_rocket_impact 
Si  detonate 

air-to-air 

attack 

opponentmissile- 

_attack 

opp_missile_launch 
opp_missile_state 
o  pp_m  issi  I  ej  impact 
Si  detonate 


interaction  class  structure  table  of  the  SOM  for 
DMTITE.  D  ue  to  space  limitations,  we  do  not  include 
all  of  the  information  that  the  complete  table  requires, 
but  it  is  all  present  in  the  actual  SO  M  .  The  basic  type  of 
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T able  3.  A  Portion  of  the  Attribute  Table  for  the  DM  TITE  Simulation  Object  M  odel 

General 

object  Derived 

Attribute 

Data 

class  object  class 

name 

type 

Cardinality 

Units 

Resolution 

Radar 

Radar  name 

char 

30 

IN/ A 

IN/ A 

frequency 

long 

N/ A 

KhZ 

IN/ A 

range 

short 

l\l/  A 

meters 

IN/ A 

power 

long 

IN/  A 

watts 

IN/ A 

beam  width 

float 

IN/  A 

degrees 

.5  degrees 

beam  height 

float 

IN/  A 

degrees 

.5  degrees 

sweep  rate 

float 

IN/  A 

degrees/  sec 

IN/ A 

location 

long 

3 

meters 

10  meters 

elevation  limits 

float 

IN/  A 

degrees 

.25  degrees 

angular  accuracy 

float 

IN/  A 

degrees 

.25  degrees 

generic  mobile  radar 

total  fuel 

short 

IN/  A 

litres 

liter 

remaining  fuel 

short 

IN/  A 

litres 

liter 

direction  of  motion 

float 

3 

IN/ A 

IN/ A 

speed 

short 

3 

km/  hour 

.5  km 

interaction  is  described  in  the  leftmost  column,  and  its 
subclasses  are  placed  in  columns  to  the  right.  With  the 
simulation  object  class  structure  and  the  interaction  class 
structure  tables  defined,  we  can  now  turn  to  the  defini¬ 
tion  of  the  types  of  i nteractions  that  D  M  T I T  E  can  par¬ 
ticipate  in  and  the  information  that  must  be  transferred 
to  allow  these  interactions  to  occur.  As  the  first  step  in 
defining  the  data  content  of  the  interactions,  the  data 
produced  and  consumed  by  each  class  must  be  defined 
and  documented  in  the  attribute  table. 

The  attribute  table  in  a  SOM  defines  the  data  at¬ 
tributes  in  each  of  the  classes  in  an  application.  U  pdates 
to  these  attributes  are  the  data  that  actually  flows  among 
the  actors  that  compose  a  D  VE.  We  have  found  that  it  is 
generally  easiest  to  first  specify  the  attributes  for  the  su¬ 
perclasses)  in  the  attribute  table  and  then  to  specify  at- 
tributes  of  the  subclasses  for  each  superclass.  In  our  ex¬ 
perience,  the  attribute  table  is  a  crucial  table  because  it 
determines  the  scope  of  the  data  that  can  be  used  in  an 
interaction.  The  omission  of  an  attribute  here  will  not 
only  affect  the  specification  of  the  interactions  for  an 


actor  but  will  also  result  in  additional  code  development 
later  in  the  project  to  rectify  the  mistake.  A  portion  of 
the  attribute  table  for  D  M  TITE  is  presented  in  T  able  3, 
and  illustrates  how  the  superclass  and  subclass  defini¬ 
tional  process  occurs.  In  Table  3,  the  superclass  we  de¬ 
fined  first  isthe  radar  class.  Within  thisclass,  ten  at¬ 
tributes  are  identified  that  are  common  to  all  of  the 
subclasses.  N  ote  that  several  attributes  have  no  resolu¬ 
tion;  this  commonly  occurs  and  is  permitted  in  the  H  LA 
specification  when  the  associated  attribute  is  an  enumer¬ 
ated  type.  Within  the  radar  class,  one  subclass  is  speci¬ 
fied,  the  generic  mobile  radar  class.  I  n  this  class,  four 
additional  attributes  are  specified.  Therefore,  in  con¬ 
junction  with  the  attributes  specified  for  the  superclass, 
every  actor  of  the  generic  mobile  radar  class  is  required 
to  publish  fourteen  attributes. 

The  last  table  to  be  specified  isthe  interaction  param¬ 
eters  table.  A  portion  of  this  table  for  the  DM  TITE 
SOM  is  presented  in  Table  4;  this  excerpt  specifies  the 
parameters  that  an  opponent  radar  must  supply  in  an 
interaction  with  a  D  M  TITE  actor.  The  parameters  re- 
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T  able  4.  A  Portion  of  the  Interaction  Parameters  Table  for  the  DMTITE  Simulation  Object  M  odel 

G eneric  interaction  1  nteraction  class 

Parameter  name 

D  atatype 

Cardinality 

radar  receive 

opponent  radar  broadcast 

initiate  opponent  broadcast 

radar  name 

char 

30 

frequency 

unsigned  long 

N/A 

range 

short 

N/A 

power 

long 

N/A 

beam  width 

float 

N/A 

beam  height 

float 

N/A 

sweep  rate 

float 

N/A 

location 

long 

3 

elevation  limits 

float 

N/A 

angular  accuracy 

float 

N/A 

opp  broadcast  state  update 

radar  name 

char 

30 

frequency 

unsigned  long 

N/A 

range 

short 

N/A 

power 

long 

N/A 

sweep  rate 

float 

N/A 

location 

long 

3 

quired  for  two  interactions  are  specified:  one  interaction 
initiates  a  radar  broadcast,  and  the  other  interaction  sup¬ 
ports  a  state  change  by  the  same  radar.  For  example, 

T  able  4  of  the  D  M  TIT  E  SO  M  specifies  that  for  an  op¬ 
ponent  radar  to  initiate  a  broadcast,  it  must  supply  ten 
parameters  to  any  D  M  T I T  E  actor  that  has  subscribed  to 
this  particular  type  of  DVE  information.  By  virtue  of 
simply  subscribing  to  this  interaction  subclass,  any 
DMTITE  actor  that  needs  information  related  to  an  op¬ 
ponent  radar  broadcast  initiation  is  guaranteed  to  receive 
the  information  from  the  opponent  host  radar  simula¬ 
tion  system.  Our  practice  is  to  place  a  parameter  in  this 
table  at  the  most  general  level  that  is  possible,  thereby 
allowing  other  actors  in  the  DVE  to  obtain  useful  infor¬ 
mation  about  our  actors,  and  vice-versa,  without  requir¬ 
ing  subscription  to  a  multitude  of  more-specific  interac¬ 
tions.  This  approach  is  by  no  means  a  standard  one,  and 
represents  our  best  estimate  of  how  to  exchange  infor¬ 
mation  within  the  DVE  at  the  lowest  computational  and 


network  bandwidth  cost.  At  the  present  time,  an  argu¬ 
ment  can  be  made  that  the  parameters  should  be  speci¬ 
fied  at  the  lowest  level  in  the  hierarchy  to  which  they 
apply,  thereby  allowing  a  remote  actor  to  specify  only 
the  interactions  that  it  needs,  and  thereby  only  receive 
the  information  it  requires.  We  do  not  find  this  argu¬ 
ment  to  be  persuasive,  but  it  will  not  be  resolved  until 
further  testing  oftheH  LA  iscompleted. 

T  he  completion  of  the  SO  M  provided  us  with  a  com¬ 
prehensive  guide  to  all  of  the  data  required  to  be  trans¬ 
ported  from  or  to  each  actor  in  D  M  THE .  The  specifica¬ 
tion  of  the  four  tables  for  the  generic  actor  classes  alone 
required  forty  pages.  U  pon  examination,  the  tables  dem¬ 
onstrate  that  massive  amounts  of  data  must  be  moved 
between  each  actor  and  the  network  interface,  and  that 
this  movement  posed  a  potential  performance  bottle¬ 
neck  for  the  system.  While  we  remained  confident  that 
our  initial  baseline  architecture  could  be  adopted  to 
meet  this  challenge,  the  amount  of  data  to  betrans- 
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ported  forced  usto  reexamine  our  approach  to  contain¬ 
erization  within  DMTITE.  Weturn  to  adiscussion  of 
this  aspect  of  D  M  THE  in  the  next  section. 

5  Containerization  Within 

the  DMTITE  Architecture 

One  of  the  issues  we  had  to  addressin  DMTITE 
was  moving  the  remote  entity  data  from  the  network  to 
each  DMTITE  actor  via  the  world  state  manager  ( W  SM  ) 
and  the  CO  D  B.  The  data  movement  between  theWSM 
and  the  CO  D  B  has  the  greatest  volume  in  the  system 
(numbers  of  bytes  per  second)  and  must  be  performed 
efficiently  to  achieve  our  performance  objectives.  Four 
issues  are  addressed  in  this  component  of  the  design. 

The  first  issue  is  that  the  system  isexpected  to  function 
within  large-scale  DVEs  and  will  have  to  receive,  pro¬ 
cess,  and  manage  large  amounts  of  data  received  over 
the  network.  U  nless  properly  managed,  these  elemen¬ 
tary  tasks  can  consume  a  significant  percentage  of  the 
computing  resources  for  the  host.  Therefore,  the  incom¬ 
ing  and  outgoing  data  management  tasks  must  be  ac¬ 
complished  in  a  manner  that  is  efficient  from  the  view¬ 
point  of  computing  resources  while  also  allowing  each  of 
the  actors  in  the  D  M  TITE  application  to  have  access  to 
current  data  about  the  state  of  the  entities  in  the  D  VE. 

The  second  issue  is  that  each  of  the  actors  in 
DMTITE  can  have  different  requirements  for  D  VE 
data,  and  the  SO  M  presented  in  the  preceding  section 
allows  for  this  eventuality.  I  n  current  H  LA  thinking, 
each  of  the  actors  in  a  system  can  specify  the  subset  of 
DVE  state  data  that  the  actor  needs  to  function  properly. 
Reciprocally,  the  actor  must  furnish  to  all  the  other 
members  of  the  D  V E  the  data  these  remote  actors  re¬ 
quire  about  the  D  M  T I T  E  actor  so  that  the  other  actors 
are  able  to  function  properly.  These  data-interchange 
requirements  are  specified  intheFOM  fortheDVE. 
While  specifying  data  requirements  for  a  single  entity  on 
a  single  machine  is  a  straightforward  process,  challenges 
arise  in  satisfying  these  needs  in  a  situation  in  which 
many  actors  reside  on  a  single  host.  The  first  of  these 
challenges  is  the  need  to  support  customized  data  trans¬ 


fers  among  actors  and  the  DVE  without  consuming  an 
inordinate  amount  of  computational  resources  by  either 
the  actor  or  the  network  portion  of  D  M  TITE.  We  be¬ 
lieve  that  each  of  the  actors  should  not  need  to  be  aware 
of  the  FO  M  requirements  for  the  D  VE  that  DMTITE  is 
participating  in;  otherwise  each  of  them  would  have  to 
assemble  specialized  outgoing  messages  for  each  of  the 
different  information  requirements  imposed  upon  it  by 
the  other  actors  in  the  DVE.  Instead,  each  actor  should 
be  allowed  to  place  all  of  the  required  outgoing  informa¬ 
tion  into  a  single  message,  and  some  other  portion  of 
the  system  should  manage  information  customization. 
This  same  approach  should  also  be  applicable  to  actor- 
specific  transfers  of  data  from  the  D  V  E  to  each  of  the 
actors  in  DMTITE.  The  second  of  these  challenges  is 
the  need  to  be  able  to  efficiently  adapt  to  changes  in  a 
FOM  ,  becauseDMTITE  will  be  required  to  participate 
in  a  wide  variety  of  FI  LA-based  DVEs.  At  the  actor  level, 
changes  in  the  FOM  will  be  reflected  in  the  data  trans¬ 
ferred  between  an  actor  and  the  DVE .  We  need  these 
changes  to  be  well  encapsulated  and  transparent  to  the 
remainder  of  the  actor's  software  and  to  most  of  the  net¬ 
work  interface  software  as  well. 

The  third  issue  that  arises  from  the  need  to  support 
FI  LA  is  the  desire  to  be  able  to  readily  adapt  to  changes 
in  the  FI  LA  standard.  We  expect  that  there  will  continue 
to  be  changes  to  the  FI  LA  that  affect  the  actor  code  and 
their  interface  to  the  DVE.  0  ur  desire  is  to  isolate  the 
actor  from  FI  LA  changes  as  much  as  possible. 

A  fourth  issue  is  the  need  to  support  our  REEP  ap¬ 
proach  to  design  and  implementation  of  DVE  applica¬ 
tions.  Support  for  REEP  requires  that  the  major  system 
components  be  isolated  from  each  other  and  that  the 
actor  code  be  separated  from  the  DVE  interface  code. 

As  a  result  of  examining  these  requirements,  we  re¬ 
fined  our  approach  to  containerization  to  better  support 
the  transport  of  data  between  the  major  components  of 
DMTITE,  as  shown  in  F  igure  3.  We  use  containers  to 
move  data  in  structured  groupings  between  the  compo¬ 
nents.  Within  DMTITE,  there  is  a  container  between 
theWSM  and  theCODB  for  every  major  entity  type, 
such  as  actors,  phenomenology,  and  electromagnetic 
emissions.  Each  container  is,  in  turn,  composed  of  pal¬ 
lets,  and  each  pallet  is  composed  of  slots.  For  example,  in 
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the  actor  container  shown  in  the  top  half  of  Figure  3 
there  are  two  major  pallets,  one  for  Blue  (friendly)  forces 
and  one  for  Red  (opponent)  forces.  Recall  that  we  are 
building  a  threat  system,  so  from  the  point  of  view  of  the 
threat  system,  the  friendly  forces  are  composed  of 
non-U  S  aircraft  and  systems  and  the  Red  forces  are  com¬ 
posed  of  U  S  aircraft  and  systems.  Within  each  of  these 
two  pallets  are  additional  pallets,  one  each  for  ground 
and  aircraft  actors.  And  within  the  Red  aircraft  pallet 
there  are  three  additional  pallets,  one  for  F- 15,  F-16, 
and  C-17  aircraft.  In  each  of  these  pallets  are  the  slots 
that  are  used  to  hold  state  information  for  each  actor  of 
that  type  within  theDVE,  the  type  being  Red  Aircraft 


F-15,  Red  Aircraft  F-16,  and  Red  Aircraft  C-17.  Each 
type  of  actor  (air,  land,  surface,  subsurface,  and  space)  as 
well  as  each  subtype  for  each  type  has  a  dedicated,  pre- 
aliocated  portion  of  the  container,  its  slot.  Each  pallet 
has  a  p re- allocated  number  of  slots  or  subpallets.  We 
allocate  an  identical  amount  of  memory  for  each  actor, 
even  though  in  some  instances  this  approach  leaves  some 
data  space  unused  for  an  individual  actor's  slot  in  the 
container,  and  even  in  some  of  the  pallets.  We  view  this 
an  acceptable  tradeoff  because  for  our  purposes  the  ob¬ 
jective  is  to  minimize  the  cost  of  moving  data  between 
the WSM  and  theCODB. 

Because  the  size  and  structure  of  the  container  are 
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static,  a  single  operation  can  move  the  data  from  the 
WSM  to  the  CO  D  B.  To  further  minimize  the  cost  of  the 
operation,  we  move  the  data  between  the  WSM  and 
C  0  D  B  using  a  double-buffering  scheme.  D  ouble  buff¬ 
ering  allows  the  WSM  to  maintain  the  state  of  the  D  VE 
without  concern  about  contention  with  the  other  system 
components  for  the  data  structures.  Asaresult,  wecan 
maintain  an  accurate  description  of  the  DVE  within  the 
WSM  while  permitting  the  major  components  of  the 
system  to  access  data  in  the  C  0  D  B  whenever  they  re¬ 
quire  the  data.  And,  conversely,  each  actor  has  conve¬ 
nient  access  to  the  data  it  needs,  and  the  CO  D  B  can  also 
prepare  the  outgoing  container  for  the  WSM  when  fill¬ 
ing  the  container  does  not  unduly  interfere  with  the  per¬ 
formance  of  the  COD  B's  other  duties.  In  this  way,  we 
can  decouple  the  operation  of  these  two  data-intensive 
components  of  D  M  T I T  E . 

0  nee  the  data  is  in  the  C  0  D  B ,  the  actors  can  access 
the  data  or  it  can  be  repackaged  into  sub-CO  D  Bsfor  use 
by  groups  of  actors  with  common  data  requirements,  as 
shown  in  F  igure  4.  Figure4  shows  that  asubset  of  the 
datain  theCODB,  the  DVE 's  aircraft,  have  been  re¬ 
packaged  and  transmitted  to  a  sub-CO  DB  in  a  container 
for  use  by  a  set  of  actors  that  have  a  common  set  of  data 


requirements.  Generally,  repackaging  would  be  per¬ 
formed  when  there  are  enough  DMTITE  actors  with 
common  data  requirements  so  that  the  expense  of  re¬ 
packaging  is  offset  by  the  time  saved  by  not  transmitting 
the  data  to  each  actor  individually.  These  sub-CO  DBs 
also  can  have  their  own  methods  attached  to  them, 
thereby  allowing  for  some  specialization  in  the  data  sup¬ 
plied  to  its  user-actors.  The  repackaging  is  performed  by 
methods  within  theCODB  class,  and  the  data  is  placed 
into  an  outgoing  container  that  is  transmitted  to  asub- 
CODB.  If  all  of  the  actors  that  access  a  given  sub- 
CO  D  B  have  identical  data  requirements,  then  we  do  not 
move  the  data  from  the  container  to  a  sub-CO  D  B;  in¬ 
stead  the  actors  access  the  single  container  directly.  In 
this  case,  we  use  a  counter  attached  to  the  container  to 
ensure  that  all  of  the  actors  serviced  by  the  container  do 
actually  get  a  chance  to  read  the  container  before  a  re¬ 
freshed  container  is  requested  from  the  CO  D  B. 

When  an  actor  must  transmit  data  to  the  DVE,  the 
actor  uses  a  container  to  transmit  the  data  to  theCODB, 
as  illustrated  in  Figure  3.  For  an  individual  actor  con¬ 
tainer,  the  container  has  the  same  format  as  its  slot  in  the 
CODB.  If  the  container  is  shared  among  several  actors, 
then  each  of  the  actors  has  an  assigned  slot  to  fill  with  its 
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data.  Once  the  container  is  ready  to  be  dispatched,  the 
CODB  signals  the  WSM  to  accept  the  data.  Each  actor 
exports  ail  of  the  data  required  by  the  SOM  for  each 
container  update:  we  rely  upon  the  WSM  and  the  H  LA 
run  time  interface  to  manage  repackaging  the  exported 
data  to  meet  the  FO  M  requirements. 

With  the  specification  of  the  data  to  be  moved— and 
having  refined  our  use  of  containerization  to  accommo¬ 
date  the  large  amount  of  data  to  be  transmitted  among 
the  major  system  components—  we  can  now  turn  to  a 
discussion  of  the  D  M  THE  architecture. 


6  The  DMTITE  Architecture 

I  n  this  section  we  describe  our  architectural  solu¬ 
tion  to  the  D  M  THE  requirements.  The  solution  incor¬ 
porates  containerization  and  theCODB,  and  addresses 
the  data  handling  issues  raised  by  the  DMTITE  SOM  . 
This  section  opens  with  an  overview  of  the  architecture 
and  the  proceeds  to  a  discussion  of  the  data  flow  within 
the  system  and  our  approach  to  achieving  the  desired 
data  flow  within  the  architectural  constraints. 

Architectural  Overview:  The  architectural  solu¬ 
tion  presented  in  Figure  5  is  based  upon  the  generic 
single  CGF  DMTITE  architecture  outlined  in  Figure  2. 
The  main  architectural  components  of  the  generic  CGF 
architecture  are  maintained  intheDMTITE  architec¬ 
ture;  however,  there  are  a  few  key  differences.  The  archi¬ 
tecture  uses  the  CO  D  B,  and  has  provision  for  multiple, 
specialized,  sub-CO  D  Bsthat  can  be  used  to  provide  in¬ 
formation  to  a  select  subset  of  the  actors  hosted  in  a 
DMTITE  system.  These  sub-CO  D  Bs  are  shared  by  their 
actors,  and  have  the  same  protection  mechanisms  and 
containerization  associated  with  them  as  the  main 
CO  D  B.  As  in  the  generic  architecture,  the  main  CODB 
and  WSM  combination  serves  to  transmit  data  to  the 
D  VE  and  to  receive  data  into  DMTITE. The  CODB 
and  all  of  its  sub-CO  D  Bsare  used  to  store  and  forward 
state  information  from  actors  hosted  by  D  M  T I T  E  to  the 
D  VE  through  the  WSM  .  The  WSM  is  responsible  for 
interfacing  with  the  H  LA  RTI .  These  two  components 
work  together  to  ensure  that  each  DMTITE  satisfies  its 


DVE  FOM  requirements  by  consolidating  the  output 
from  the  actors  and  then  transmitting  the  actor  state 
data  to  the  rest  of  the  DVE  in  a  manner  that  satisfies  the 
FOM  .  Within  an  individual  DMTITE  system,  each  actor 
threat  type  shares  a  knowledge-base  set  that  was  as¬ 
sembled  specifically  for  its  actor  type.  FI  owever,  while 
the  knowledge  bases  for  a  specific  actor  type  are  shared 
by  all  of  the  actors  of  that  type  at  run-time,  not  all  of  the 
actors  utilize  all  of  the  knowledge  base's  information. 
The  information  accessed  from  the  knowledge  bases  is 
determined  by  the  fidelity  level  and  skill  level  required  of 
each  actor  instantiation.  C  urrently,  the  knowledge  bases 
are  read-only  at  run-time.  The  decision  mechanisms 
within  each  threat  actor  are  instantiated  along  with  the 
actor  and  are  not  shared  between  instantiations.  Because 
knowledge  bases  are  shared  between  threats,  the  difficult 
and  expensive  knowledge-base  construction  process 
must  be  accomplished  only  once,  but  the  burden  of 
achieving  different  levels  of  fidelity  and  skills  falls  upon 
the  decision  mechanisms  and  their  use  of  the  knowledge 
bases. 

Even  though  the  architecture  in  Figure  5  resembles 
that  of  Figure  2,  a  few  words  of  explanation  of  the  differ¬ 
ences  between  it  and  Figure  2  are  in  order.  The  opera¬ 
tion  of  the  network  interface  and  network,  WSM  ,  and 
the  dead-reckoning  engine  are  the  same  as  that  for  the 
basic  architecture.  Once  the  DVE  state  information 
reaches  the  CODB,  the  data  is  repackaged  into  outgoing 
containers  for  either  individual  actors  or  for  a  single  ac¬ 
tor  class.  This  repackaging  is  accomplished  by  an  object 
manager.  0  nee  the  DVE  state  reaches  a  sub-C  0  D  B,  the 
data  isdispatched  from  there  in  containers  to  the  actors 
serviced  by  the  sub-CO  D  B.  The  containers  that  depart 
the  CO  D  B  or  a  sub-CO  D  B  for  an  actor  are  customized 
for  the  actor,  and  contain  only  the  DVE  information 
required  by  the  actor  as  specified  in  the  SOM  .There  are 
two  components  of  the  threat  database  for  each  actor 
type:  the  environment  database  and  the  mission,  strat¬ 
egy,  and  tactics  database.  The  environment  database  for 
each  actor  type  contains  the  specification  of  the  terrain 
and  other  static  portions  of  the  D  VE  in  visible  wave¬ 
lengths  as  well  as  the  wavelengths  used  by  the  actor's 
sensors.  T  he  other  portion  of  the  threat  database  con¬ 
tains  the  information  about  the  individual  actor's  mis- 
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Figure  5.  DMTITE  system  architecture. 


sion,  the  tactics  for  the  threat  type,  and  the  strategies  to 
be  employed  by  the  threat  type.  Within  each  actor 
threat,  the  skills  component  remains  as  described  previ¬ 
ously  for  the  individual  actor  case.  Theonly  changeto 
the  active  decisions  component  was  the  replacement  of 
the  basic  control  module  by  the  arbitration  engine  (AE). 
The  function  of  theAE  isto  determine  which  of  thede- 
cision  engine  outputs  should  be  used  as  the  actor's  next 
action.  We  changed  the  name  of  this  component  to  re¬ 
flect  the  fact  that  its  decision  making  became  more  com¬ 
plex  so  that  the  system  could  better  select  the  output  to 
use  and  also  because  theAE  can  employ  a  variety  of  de¬ 


cision-making  mechanisms  when  arbitrating  over  the 
outputs  from  the  other  decision  engines  in  the  ADC. 
The  functionality  of  the  physical  dynamics  component 
was  unchanged. 

When  an  actor  has  computed  its  new  state,  this  infor¬ 
mation  must  be  provided  to  the  other  actors  in  the 
DMTITE  application  at  the  host  as  well  as  to  the  other 
actors  in  the  DVE.  To  accomplish  this  data  transfer,  the 
actor  places  its  state  information  into  a  container  that  is 
then  dispatched  to  theCODB  (possibly  viaaseriesof 
sub-CO  D  Bs)  for  relay  to  the  WSM  .  0  nee  the  new  state 
data  is  in  theCODB,  the  actor  data  is  passed  on  to  the 
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WSM  for  transmission  to  the  DVE  and  is  also  repack¬ 
aged  into  the  next  outbound  container  to  leave  the 
CODB  for  the  actors  in  the  local  DMTITE  application. 

DMTITE  Data  Flow  and  Data  Filtering:  Within 
the  DMTITE  H  LA  operational  environment,  each  sys¬ 
tem  has  perfect  knowledge  about  the  state  of  all  of  the 
entities  in  the  DVE,  which  is  an  inaccurate  portrayal  of 
the  real-world  operational  environment.  The  inaccuracy 
arises  from  the  fact  that  known  sensor  limitations  are  not 
imposed  upon  the  data;  therefore,  each  sensor  has,  in 
effect,  unlimited  visibility  coupled  with  unlimited  sensi¬ 
tivity.  Asaresult,  theCGAswithin  DMTITE  could  have 
knowledge  about  the  state  of  the  D  V  E  and  the  entities 
in  it  that  is  unavailable  to  their  real-world  counterparts 
under  similar  environmental  and  sensor  conditions.  T o 
address  this  issue  and  increase  the  fidelity  of  the  opera¬ 
tion  of  D  M  TITE  actors  within  the  DVE,  each  threat 
within  a  DMTITE  system  has  its  information  restricted 
by  filtering  the  incoming  data  so  that  the  CGA  threat 
operatesonly  upon  a  realistic  set  of  information.  Figure 
6  illustrates  how  this  is  accomplished  within  the 
DMTITE  architecture. 

F  igure  6  presents  our  approach  to  DVE  data  filtering 
for  a  single  actor.  Whenever  a  threat  application  acquires 
DVE  state  information,  the  information  must  always 
come  through  the  CODB.  H  owever,  before  the  actor 
operates  upon  the  information  in  its  container,  the  infor¬ 
mation  is  filtered  by  sensor  models.  The  sensor  models 
restrict  the  information  provided  to  the  actor  so  that  the 
information  available  to  the  actor  matches  that  provided 
to  a  real-world  counterpart  system.  After  filtering,  the 
environment  data  is  used  in  conjunction  with  the  knowl¬ 
edge  bases  by  the  decision  engines  (DEs)  for  their  deci¬ 
sion-making  computations.  TheAE  takes  the  results 
from  each  DE  and  decides  which  of  the  results  should  be 
used  as  the  output.  The  decisions  from  theAE  are  then 
forwarded  to  the  C  0  D  B  where  other  threat  compo¬ 
nents  within  DMTITE  and  in  the  DVE  acquire  the  out¬ 
puts  for  their  computations. 

The  above  model  for  data  filtering  is  acceptable  for  a 
single- actor  system,  but  the  requirement  to  host  more 
than  one  actor  in  a  D  M  TITE  necessitates  a  modified 
approach  to  data  filtering  when  multiple  actors  are  using 
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Figure  6.  Distributed  virtual  environment  data  flow  through 
the  application  for  an  individual  DMTITE  threat. 


the  dynamic  environment  data  in  a  single  COD  B.  0  ur 
model,  as  shown  in  Figure  6,  places  all  of  the  informa¬ 
tion  that  an  actor  requires  for  decision  making  into  the 
actor's  knowledge  base.  The  difficulty  arises  from  the 
fact  that  in  D  M  TITE  the  dynamic  environment  data 
destined  for  an  actor  type  is  transferred  to  the  actors 
within  a  single  container,  which  isthen  operated  upon 
by  a  single  sensor  model  before  it  is  placed  into  the 
knowledge  base.  By  virtue  of  the  knowledge  base  being 
shared  by  all  of  the  actors  of  a  single  type,  the  output  of 
the  sensor  model  is  then  shared  by  all  of  the  actors  of  a 
type,  even  though  the  actors  do  not  have  identical  sensor 
input  requirements.  Therefore,  we  modified  our  model 
for  the  information  flow  from  the  DVE  to  each  indi¬ 
vidual  actor.  This  new  information  flow  model  is  de¬ 
picted  in  Figure  7. 

Asshown  in  F  igure  7,  the  transfer  of  data  from  the 
CO  D  B  to  the  actor  is  now  mediated  by  new  operations. 
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Figure  7.  Processing  of  world  state  data  using  actor-specific  sensor  models  within  DM  TITE . 


As  before,  the  information  from  the  CO  D  B  required  by 
an  actor's  SO  M  is  dispatched  via  a  container  to  the  actor. 
H  owever,  instead  of  the  actor  accessing  the  container 
directly,  the  actor  accesses  the  data  after  it  has  been  pro¬ 
cessed  and  placed  in  the  physical  state  information  inter¬ 
face.  Recall  that  each  CODB  has  methods  attached  to  it 
to  manage  the  packing  and  unpacking  of  the  container. 
We  built  upon  this  method-based  access  to  implement 
filtering.  In  our  revised  approach  to  DVE  state  filtering, 
actor  data  access  is  initiated  upon  the  arrival  of  a  new 
container  from  the  CO  D  B. 

The  container  unpackaging  software,  called  the  sensor 
interface,  extracts  data  from  the  container  and  forwards 
it  to  the  sensor  models,  called  the  physical  component, 
for  processing.  H  owever,  this  approach  to  DVE  state 
filtering  is  not  complete  because  it  ignores  processing 
that  may  have  to  be  performed  to  support  decision  mak¬ 
ing  when  phenomenology  and  weapon  systems  (both 
friend  and  foe)  must  be  considered  in  the  decision-mak¬ 
ing  process.  These  considerations  resulted  in  additional 
change  to  the  architecture,  as  shown  in  the  diagram  in 
Figure8. 

F  igure  8  presents  the  final  view  of  the  D  M  T I T  E  archi¬ 
tecture.  In  this  figure  we  emphasize  the  data  flow  and 
sensor  interaction  aspects  of  the  architecture.  This  view 
of  the  architecture  illustrates  how  the  architecture  sup- 
portsthe  data  flows  and  information-filtering  objectives 
presented  in  Figure  5  and  Figure  7.  To  keep  the  diagram 
as  uncluttered  as  possible  and  to  better  illustrate  the  data 
flow  for  sensor  filtering,  the  containers  and  CODB  have 
been  omitted  from  this  diagram,  but  they  are  still  pres¬ 
ent  in  the  architecture.  In  the  revised  DM  TITE  architec¬ 
ture,  we  model  sensor  data  filtering  and  the  actor's  re¬ 
sponse  to  the  filtered  data  as  a  two-stage  process.  The 
first  stage  is  modeling  of  the  physical  world  state,  and 
the  second  stage  is  reasoning  upon  the  resulting  state 


information.  The  reasoning  outputs  are  then  used  to 
control  the  actor,  to  feedback  into  the  data  filtering  pro¬ 
cess,  and  to  generate  outputs  for  the  DVE. 

I  n  this  version  of  the  architecture,  the  sensor  interface 
still  serves  as  a  data  warehouse  and  data  router  between 
the  container  and  the  physical  component  models.  The 
physical  component  models  the  physical  operation  of  the 
sensors  and  incorporates  phenomenology  and  weapon 
information  into  its  filtered  output  DVE  state  informa¬ 
tion.  The  output  of  the  physical  component  is  passed  to 
the  decision-making  component  via  the  physical  state 
information  interface  (PSI I ).  The  PSI I  stage  of  DVE 
state  processing  routes  the  information  from  a  physical 
component  to  the  actor-specific  knowledge  bases  that 
require  the  particular  type  of  information  produced  by  a 
sensor.  The  operation  of  the  PSI  I  in  many  ways  parallels 
that  of  the  CO  D  B:  the  PSI  I  functions  as  a  run-time  data 
repository  for  the  physical  model  computations  of  the 
sensor  outputs  and  passes  the  information  to  the  deci¬ 
sion-making  components  of  the  actor  that  requires  the 
information.  The  incoming  DVE  statedata  isused  in 
conjunction  with  the  information  contained  in  the  actor- 
type,  specific-threat  knowledge  bases  by  the  SD  E ,  T  D  E , 
and  C  D  E  to  perform  their  long-range,  mid-range  and 
immediate  decision-making  functions.  TheSDE,  TDE, 
and  C  D  E  place  the  outputs  of  their  computations  into 
theAE,  which  selects  the  actions  that  are  fed  back  to  the 
physical  components  to  be  acted  upon,  the  dynamics 
and  sensor  components,  and  can  also  be  sent  out  to  the 
DVE  asweil. 


7  DMTITE  System  Design 

The  design  for  D  M  TITE  is  object  based  and 
strongly  reflects  the  structure  suggested  by  the 
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Figure  8.  Data  flow  through  the  DMTITE  architecture. 


DMTITE  architecture.  We  endeavored  to  maintain  a 
straightforward  mapping  between  the  elements  of  the 
architecture  and  the  design  for  several  reasons.  We  be¬ 
lieved  that  a  close  mapping  would  allow  us  to  better 
trace  the  effects  of  the  architecture  on  the  eventual 
implementation,  would  provide  us  with  a  system  that 
was  readily  explainable  and  easily  modified,  and  would 
also  allow  us  to  readily  identify  elements  of  the  architec¬ 
ture  and  design  that  required  changes  if  problems  were 
identified.  The  design  description  that  we  present  in  the 
next  few  pages  is  current  at  the  time  of  this  writing  and 
reflects  the  effects  of  several  iterations  on  both  the  archi¬ 
tecture  and  design.  Wewill  first  discuss  the  design  ofthe 
C  0  D  B  component  in  this  section  and  then  conclude 
with  a  discussion  of  the  design  for  the  DMTITE  actor 
software.  All  of  the  software  is  written  in  C  +  +  for  Sili¬ 
con  Graphics  computers  running  I  RIX  6.2. 

The  common  object  database  design:  The 

CO  D  B  is  crucial  to  the  effective  operation  of  D  M  TITE 


because  all  incoming  and  outgoing  DVE  information  is 
maintained  by  and  routed  through  it.  I  n  the  design  of 
theCODB,  the  most  important  issues  were  ensuring 
uncorrupted  access  to  the  data  in  the  containers  and 
structuring  the  CO  D  B  and  its  containers  to  hold  all  of 
the  information.  To  simplify  the  data  management  pro¬ 
cess,  we  decided  to  maintain  a  strict  separation  between 
the  containers  that  bring  in  data  to  an  actor  from  the 
C  0  D  B  and  those  that  send  data  from  the  actor  to  the 
CODB.  When  information  comesinto  an  actor,  thedata 
comes  in  a  container  that  is  read-only  for  the  actor  and 
write-only  for  the  COD  B.  When  state  information  de¬ 
parts  an  actor,  it  is  placed  in  a  container  that  is  write- 
only  to  the  actor  and  read-only  for  the  CO  D  B. 

I  n  the  design  of  the  container  class,  we  also  differenti¬ 
ate  between  persistent  and  nonpersistent  data.  Persistent 
data  is  data  tied  to  an  entity  that  has  a  relatively  long 
lifespan  in  the  DVE,  but  some  components  of  the  persis¬ 
tent  data  may  change  over  time.  For  example,  the  exis¬ 
tence  of  an  entity  in  the  DVE  is  a  relatively  persistent 
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piece  of  data  even  though  its  velocity  and  location,  and 
hence  its  state,  may  be  continuously  changing.  Nonper- 
sistent  data,  on  the  other  hand,  is  usually  a  singular 
event,  has  a  relatively  brief  lifespan,  and  is  needed  by 
each  D  M  T I T  E  actor  only  once.  For  example,  a  weapon 
detonation  is  a  nonpersistent  event,  and,  typically,  once 
an  actor  has  processed  the  fact  that  a  weapon  detonated, 
the  actor  no  longer  needs  the  information.  For  persistent 
and  nonpersistent  data  containers,  the  readers  are  moni¬ 
tored.  When  all  readers  of  a  persistent  data  container 
have  accessed  the  container,  the  container  is  updated 
with  new  information.  I  n  the  case  of  a  nonpersistent 
data  container,  once  all  the  readers  have  accessed  the 
container,  the  container's  contents  are  discarded,  and 
the  container  becomes  available  to  hold  information 
about  the  next  transient  D  VE  event  to  occur. 

A  persistent  container  holds  DVE  entity  state  data, 
data  that  specifies  the  type  of  container  (entity,  phenom¬ 
enology,  etc.),  and  four  additional  fields  that  specify 
wherein  the  container  the  information  for  the  destina¬ 
tion  object  is  stored.  The  four  additional  fields  provide 
the  actor  with  a  map  of  the  data  in  the  container,  so  that 
the  location  in  the  container  of  the  palettes  of  informa¬ 
tion  and  even  individual  actor  state  data  are  specified. 
The  CO  D  B  obtainsthe  information  concerning  the 
types  of  information  each  actor  is  interested  in  when  the 
actor  is  initialized.  When  an  actor  is  initialized,  it  con¬ 
nects  to  the  CO  D  B  and  specifies  the  information  that  it 
requires  and  the  types  of  information  that  it  will  supply 
(which  must  be  identical  to  the  information  specified  in 
the  SO  M ).  When  the  actor  has  information  that  is  ready 
to  be  transmitted,  the  actor  loads  its  container  and  then 
sends  the  information  to  the  CO  D  B  by  connecting  to 
the  CO  D  B  and  informing  the  CO  D  B  that  its  outbound 
container  is  ready.  As  part  of  the  data  passed  atthistime, 
the  actor  also  informs  the  CO  D  B  which  portions  of  the 
actor's  container  have  changed  since  the  last  container 
was  sent  by  that  actor.  C  onversely,  when  the  C  0  D  B  has 
information  ready  for  an  actor,  theCODB  connects  to 
the  actor  and  informs  the  actor  that  theCODB  out¬ 
bound  container  for  the  actor  is  ready  and  of  those  por¬ 
tions  of  the  container  that  have  changed  since  the  last 
container  was  dispatched  to  the  actor.  The  information 
passed  by  the  C  0  D  B  includes  data  on  the  number  of 


entriesin  the  container  (which  is  fairly  constant  as  this 
value  only  changes  when  an  entity  that  the  actor  has  re¬ 
quested  information  about  enters  or  leaves  the  DVE), 
the  entity  I D  for  each  container  entry,  and  the  location 
in  the  container  of  the  entity's  data.  Because  the  writer 
controlsthe  dispatch  of  the  container  to  the  reader,  we 
do  not  need  to  address  mutual-exclusion  issues  in  the 
design.  H  owever,  one  issue  addressed  is  of  multiple 
readers  of  the  same  container  or  sub-CODB.  To  ensure 
that  all  entities  that  require  data  from  the  container  or 
sub-CODB  have  a  chance  to  read,  we  attach  a  counter 
to  the  container.  T  he  counter  is  incremented  when  an 
entity  finishes  its  read,  and,  when  the  counter  value 
matches  the  number  of  readers  for  the  container  or  sub- 
CO  D  B,  then  the  last  entity  to  increment  the  counter 
connects  and  signals  that  new  data  is  required.  Of 
course,  a  semaphore  protects  the  counter  value. 

The  DMTITE  Actor  Software  Design:  0  ur  ap¬ 
proach  to  the  design  of  the  software  to  implement  each 
DMTITE  actor  was  to  develop  a  set  of  objects  that  mir¬ 
ror  the  architecture  in  the  major  system  components  for 
each  actor,  as  shown  in  Figure  9.  For  each  actor  in  the 
DMTITE  application,  we  have  four  main  objects,  the 
physical  representation  component,  the  physical  state 
information  interface,  the  dynamics  component,  and  the 
cognitive  representation  component.  Each  of  these  four 
components  is  in  turn  composed  of  a  variety  of  addi¬ 
tional  objects. 

The  physical  representation  component  (PRC)  has 
two  major  subobjects,  the  physical  model  and  the  sensor 
interface.  The  physical  model  component  implements 
the  functionality  of  the  physical  component  called  for  in 
the  architecture.  The  implementation  of  this  object  al¬ 
lows  us  to  encapsulate  one  or  more  physical  models  for 
the  operation  of  a  sensor  within  a  single  package  for  the 
actor,  and  each  actor  can  have  one  or  more  physical 
models.  Because  the  information  that  is  provided  to  the 
physical  model  is  encapsulated  within  a  standardized 
state  message,  we  can  interchange  different  physical 
modelsto  change  sensor  functionality  in  an  actor.  Also, 
because  we  hide  the  physical  model'sfunctionality,  we 
have  been  able  to  incorporate  existing  sensor  models 
into  DMTITE  with  relative  ease.  The  other  component 
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of  the  PRC  is  the  sensor  interface.  The  sensor  interface  is 
responsible  for  extracting  information  from  the  incom¬ 
ing  container  and  providing  each  sensor  model  with  the 
information  that  it  requires  to  function.  The  information 
is  transferred  from  the  sensor  model  to  the  physical  state 
information  interface  using  a  state  message.  Once  the 
sensor-filtered  information  is  in  the  physical  state  infor¬ 
mation  interface,  the  information  is  incorporated  into 
the  knowledge  base  repository  for  use  by  the  decision 
engines. 

Each  D  M  TIT  E  actor  contains  the  four  D  Es  shown  in 
Figure  9.  Each  of  the  four  D  Es  contain  a  set  of  knowl¬ 
edge  base  I D  s  and  variables.  The  knowledge  base  I  D  s 
identify  the  knowledge  bases  that  the  actor  will  use  for 
decision  making.  Each  of  the  DEscan  use  a  different 
type  of  reasoning  mechanism  for  its  operation,  the 
choice  of  decision  mechanism  for  an  engine  is  com¬ 
pletely  independent  of  the  type  of  decision-making 
mechanisms  used  in  the  other  three  engines.  The  only 
requirement  that  we  impose  upon  the  D  Es  is  that  their 
decision-making  systems  be  completely  self-contained. 
The  knowledge  bases  are  also  constructed  independently 
of  the  D  E  s,  one  of  the  requirements  that  we  impose  on 
the  knowledge  bases  is  that  the  information  they  provide 
must  be  able  to  be  presented  to  each  of  the  D  Esin  a  for¬ 
mat  that  is  useful  to  the  reasoning  mechanism  used  by 
the  particular  D  E  being  served.  The  A  E  hasone  unique 
aspect  missing  from  the  other  three  engines,  it  contains  a 
combat  skills  (CS)  model.  An  example  of  the  use  of  aCS 
model  iscontained  in  Figure  10. 

I  n  Figure  10,  we  present  a  rule  for  specifying  how 
anxiety  and  anger,  the  skill  variables,  combine  to  affect 
reaction  time.  The  rule  isthat  if  anxiety  has  a  value  that 
exceeds  0.70,  and  if  the  value  for  anger  exceeds  0.50, 
then  the  CGA's  reaction  time  is  increased.  Thisrulecan 
be  used  for  all  levels  of  skill  for  a  type  of  CG  A  because 
the  outcome  of  the  evaluation  of  thisruleforaCGA  is 
dependent  upon  two  types  of  variables,  trait  variables 
and  effects  variables,  and  their  combined  effect  upon  a 
skill  variable  and  not  upon  any  data  contained  in  the  rule 
itself.  A  trait  variable  value  is  constant  for  each  modeled 
skill  used  by  the  CG  A  throughout  the  entire  time  it  op- 
eratesin  the  DVE.  Forexample,  theCGA  in  Figure  10 
has  little  experience  in  combat  but  has  an  aggressive  atti¬ 


tude.  Because  of  the  lack  of  experience  coupled  with  a 
positive  attitude  toward  being  in  combat,  the  anxiety 
trait  is  set  to  a  value  of  0.15,  which  indicates  that  the 
CGA  will  be  more  anxious  than  a  veteran,  but  calmer 
than  most  inexperienced  pilots.  The  value  for  the  anger 
trait  is  set  to  0.45  to  reflect  the  CGA's  inexperience;  we 
would  expect  an  inexperienced  human  in  similar  circum¬ 
stances  to  be  somewhat  angry  at  the  enemy.  From  time 
to  time  during  the  course  of  its  operation,  theCGA  will 
encounter  situations  that  can  cause  anxiety,  anger,  or 
both  to  change.  These  dynamic  changes  to  theCGA 
combat  skills  are  reflected  in  the  effects  variables.  I  n  the 
situation  reflected  in  FigurelO,  the  loss  of  the  lead  air¬ 
craft  while  under  attack  by  overwhelming  force  affects 
both  the  anger  and  anxiety  skill  variables.  Because  of  the 
oddsagainst  the  CGA  surviving  the  encounter  are  in¬ 
creased,  anxiety  should  also  increase.  The  value  of  0.30 
for  the  anxiety  effects  variable  reflects  this  change.  FI  ow- 
ever,  the  situation  also  affects  the  CGA's  anger  effects 
value,  which  we  set  to  0.10  to  reflect  the  loss  of  the  lead 
aircraft  and  pilot.  To  determine  if  the  rule  should  fire, 
the  values  for  trait  and  effect  are  summed  to  yield  an 
instantaneous  value  for  their  associated  skill  variable.  In 
this  circumstance,  the  anxiety  skill  variable  has  a  value  of 
0.45  and  the  anger  skill  variable  has  a  value  of  0.55,  so 
the  rule  does  not  fire. 

The  combat  skills  model  is  used  bytheAE  to  refine 
the  outputs  from  the  D  Esto  match  the  skill  level  desired 
for  the  particular  actor.  The  CS  model  provides  us  with  a 
means  to  depict  aggressiveness,  ability,  capability  to  an¬ 
ticipate  enemy  maneuvers,  and  ability  to  apply  knowl¬ 
edge  as  expressed  by  the  doctrine  and  tactics  contained 
in  the  knowledge  bases.  I  n  addition,  the  C  S  model  al¬ 
lows  us  to  portray  a  particular  actor's  promptness  in 
obeying  orders,  the  actor's  morale  and  anxiety  about  its 
mission,  and  the  simulated  eyesight  acuity  for  the  actor. 
When  required,  we  can  establish  a  new  skill  level  by 
specifying  the  appropriate  parameters  for  the  CS  model. 
The  skill  model  is  used  in  conjunction  with  the  knowl¬ 
edge  bases  needed  bytheAE  decision-making  mecha¬ 
nisms  to  select  outputs  from  those  provided  by  the  other 
D  Esso  that  the  actions  performed  by  the  actor  match  its 
desired  skill  level.  Within  theAE,  theCS  model  can  be 
rule-based,  case-based  or  fuzzy-set  based;  in  this  regard 
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Figure  9.  Software  design  fora  DM TITE  computer-generated  actor. 
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Rule:  If  anxietv  >  0.70  and  aneer  <  0.50  then  reaction  time  is  increased 

.45 

Anxiety  trait  =  0.15 

Anxiety  effects  =  0.30 

.55 

Anger  trait  =  0.45 

Anger  effects  =0.10 

Figure  10.  Combat  psychology  model  example  for  an  aggressive  CGA  that  is  inexperienced  in  combat  reacting  to  the  shootdown 
of  its  lead  while  being  attacked  by  overwhelming  force. 


the  AE  operates  like  all  the  other  D  Esin  that  it  does  not 
know  how  the  information  is  represented  in  its  knowl¬ 
edge  bases.  By  isolating  the  skill-level  properties  for  the 
actor  within  a  single  component  of  the  C  RC ,  we  can 
more  easily  specify  a  skill  level  than  if  we  distributed  this 
aspect  of  the  actor's  decision  making  capability  among 
all  four  of  the  decision  engines. 

The  knowledge  base  repository,  portrayed  in  Figure 
11,  isthe  final  component  of  the  D  Esdesign.  The 
knowledge  base  repository  holds  all  of  the  knowledge 
required  by  an  actor.  The  components  of  an  actor's 
knowledge  base  are  specified  when  it  is  configured,  and 
each  of  the  decision  engines  is  thereby  able  to  access  the 
repository  when  required  by  using  these  I  Ds. 

In  Figure  11,  theexpression  class  establishes  the  ac¬ 
cess  methods  to  an  expression.  The  access  methods  are 
independent  of  the  reasoning  strategy  used  by  a  decision 
engine  or  the  type  of  knowledge  expression  contained, 
such  as  case-based,  rule-based,  or  fuzzy  logic.  As  shown 
in  the  figure,  within  the  knowledge  base  repository  are  a 
number  of  knowledge  bases.  A  DMTITE  knowledge 
base  is  composed  of  a  set  of  policies.  A  policy  is  a  self- 
contained  unit  of  knowledge,  for  example,  a  checklist  for 
dealing  with  in-flight  emergencies.  Policies  are  atomic 
and  nonoverlapping;  they  do  not  rely  upon  knowledge 
contained  in  other  knowledge  bases  within  DMTITE. 
Thisapproach  to  knowledge  partitioning  allowsusto 
expand  the  contents  of  a  knowledge  base  by  adding  poli¬ 


cies  to  a  knowledge  base  or  by  extending  the  contents  of 
an  individual  policy.  Policies  and  knowledge  bases  can  be 
shared  among  actors  in  D  M  TITE .  A  policy,  as  shown  in 
the  diagram,  can  be  either  a  basic  policy  (currently  sup¬ 
ports  case- based  or  rule-based  reasoning)  or  a  fuzzy 
policy  (one  that  supports  fuzzy  logic). 

I  n  D  M  T I T  E ,  because  the  knowledge  implementation 
is  separated  from  the  reasoning  engine  that  acts  upon 
that  knowledge,  the  D  E  s  need  to  know  only  which 
knowledge  bases  to  access  for  information,  which  is  pro¬ 
vided  in  knowledge  base  I D  s,  and  the  manner  for  ex¬ 
tracting  knowledge  from  the  particular  knowledge  base, 
which  is  provided  in  the  policy.  This  separation  of 
knowledge  and  reasoning  engine  allowsusto  experi¬ 
ment  with  different  types  of  knowledge  representations 
and  decision  mechanisms  without  changing  the  software 
design. 

The  fourth  and  final  component  of  every  DMTITE 
actor  is  its  dynamics  component.  The  dynamics  compo¬ 
nent  holds  the  dynamics  model  for  the  actor  and  is  used 
to  move  the  actor  throughout  the  D  VE  in  a  realistic  and 
accurate  manner.  Each  actor  has  at  least  one  model  and 
may  have  several.  If  the  actor  has  several  dynamics  mod¬ 
els,  we  generally  attempt  to  construct  them  so  that  we 
have  several  different  levels  of  dynamics  fidelity  to 
choose  from.  I  n  this  way,  when  an  actor  must  move  in  a 
highly  accurate  manner  for  a  particular  scenario,  we  can 
employ  a  high-fidelity  model,  but,  in  other  circum- 
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Figure  11.  The  design  of  the  DMTITE  actor  knowledge  base  repository. 


stances  when  dynamics  is  not  as  important  and  we  need 
to  con  serve  computational  power,  we  can  employ  a 
lower-fidelity  model  that  consumesfewer  C  PU  re¬ 
sources. 


8  Summary  and  Future  Work 

I  n  this  paper  we  presented  an  architectural  solution 
to  the  requirements  for  a  distributed  mission  training 
threat  system.  The  architectural  solution  is  based  on  the 
CO  D  B  architecture  and  permits  the  use  of  REE  P,  en¬ 
sures  the  isolation  of  reasoning  components  from 
knowledge-base  components,  permits  multiple  threats 


to  be  instantiated  within  asingleDMTITE  host,  and 
restricts  available  information  to  a  model  of  the  informa¬ 
tion  available  in  the  real  world. 

Several  issues  remain  to  be  addressed  in  DMTITE  and 
in  CGAsasafield.  0  ne  of  the  most  pressing  issues  is  the 
cost  of  assembling  a  knowledge  base  for  an  actor.  As 
might  be  expected,  the  cost  of  the  knowledge  base  in¬ 
creases  with  the  complexity  of  an  actor's  desired  behav¬ 
ior,  so  that  when  an  actor  must  faithfully  emulate  an  air¬ 
craft  the  amount  of  knowledge  required  is  quite 
overwhelming.  0  ne  step  we  took  in  DMTITE  to  ame¬ 
liorate  this  problem  was  incorporating  the  capacity  to 
reuse  knowledge  bases  across  actor  types.  0  ur  goal  is 
that  we  will  have  to  assemble  and  maintain  a  particular 
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knowledge  base  only  once.  H  owever,  this  solution  is  not 
a  final  one,  and  we  do  not  foresee  a  solution  until  better 
models  of  human  behavior  are  developed.  At  this  stage 
of  CGA  development,  we  have  no  model  to  guideusin 
the  selection  of  information  to  be  included  in  a  knowl¬ 
edge  base,  and  we  are  generally  forced  to  rely  upon  sub¬ 
ject-matter  experts  to  furnish  guidance.  H  owever,  this  is 
a  notoriously  slow  procedure. 

Another  pressing  issue  is  the  need  to  be  able  to  vali¬ 
date  the  behaviors  of  a  CGA  without  examining  all  of 
the  possible  DVE  states  to  ensure  that  the  response  of 
the  CGA  is  correct.  We  do  not  see  a  quick  solution  to 
this  problem,  but  it  may  lie  in  being  able  to  be  addressed 
by  reusing  knowledgebases,  validating  behaviors  against 
standardized  scenarios,  and  by  developing  better  behav¬ 
ioral  models.  I  n  any  regard,  the  development  of  better 
behavioral  models  is  an  important  problem  because  it  is 
the  only  tool  we  have  to  guide  us  in  the  development  of 
CGA  capabilities  and  in  populating  knowledgebases. 

Another  question  that  remains  unanswered  isthe 
number  of  actors  that  should  be  serviced  byaCODB  or 
sub-CODB.  Asthenumber  of  actors  per  COD  B  orsub- 
CO  D  B  increases,  the  system  saves  time  in  moving  data 
to  the  actor,  but  the  amount  of  time  required  for  all  the 
actors  to  retrieve  their  data  increases.  Asthenumber  of 
actors  per  sub-C  0  D  B  decreases,  the  servicing  time  de¬ 
creases,  but  the  proportional  amount  of  time  required  to 
move  data  to  a  sub-CO  D  B  or  servicing  container  in¬ 
creases.  We  suspect  that  the  number  of  actors  serviced 
will  depend  upon  the  acceptable  delay  in  data  arrival  that 
the  actors  can  tolerate,  the  number  of  actors  per  CPU  , 
and  the  amount  of  data  that  must  be  loaded  into  the 
container. 

The  final  issue  we  believe  should  be  addressed  isthe 
challenge  of  skill  levels.  As  we  currently  conceive  of  the 
problem,  skill  level  and  fidelity  are  separable  in  a  system, 
but  we  have  no  evidence  to  support  this  conjecture.  An¬ 
other  component  of  this  issue  is  that  of  properly  defining 
the  skill  level  for  an  actor  in  a  way  that  a  computer  can 
use  to  modify  the  output  from  a  decision  process.  We 
have  taken  a  first  step  in  this  direction  with  the  use  of  a 
combat  skill  model,  but  this  model  is  by  no  means  a 
complete  picture  of  the  skills  that  an  operator  bringsto 


bear  when  using  a  system.  The  combat  skill  model  ad¬ 
dresses  the  psychological  aspects  of  the  operator,  which 
are  those  issues  that  relate  to  aggressiveness  and  willing¬ 
ness  to  engage  in  combat  and  a  few  physical  attributes, 
such  as  eyesight  acuity.  H  owever,  the  model  needsto  be 
expanded  to  account  for  physical  factors,  such  as  toler¬ 
ance  of  G  forces,  exhaustion,  and  physical  coordination, 
as  well  as  additional  psychological  factors  such  as  mental 
alertness,  creativity,  and  the  ability  to  improvise. 
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